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Preface 



Computer Aided Design (CAD) technology plays a key role in today's advanced 
manufacturing environment. To reduce the time to market, achieve zero defect quality the 
first time, and use available production and logistics resources effectively, product and design 
process knowledge covering the whole product life-cycle must be used throughout product 
design. Once generated, this intensive design knowledge should be made available to later 
life-cycle activities. Due to the increasing concern about global environmental issues and 
rapidly changing economical situation worldwide, design must exhibit high performance not 
only in quality and productivity, but also in life-cycle issues, including extended producer's 
liability. 

These goals require designers and engineers to use various kinds of design knowledge 
intensively during product design and to generate design information for use in later stages of 
the product life-cycle such as production, distribution, operation, maintenance, reclamation, 
and recycling. Therefore, future CAD systems must incorporate product and design process 
knowledge, which are not explicitly dealt with in the current systems, in their design tools 
and design object models. 

Between 1987 and 1989, the IFIP Working Group 5.2 organized a series of three 
workshops on “Intelligent CAD,” which were followed by a working conference on the same 
subject in 1991. To address the above issues, a new series of workshops was begun in 1995 
which extends the concept of intelligent CAD to the concept of “knowledge intensive 
engineering.” The concept advocates that intensive life-cycle knowledge regarding products 
and design processes must be incorporated in the center of the CAD architecture. The concept 
focuses on the systematization and sharing of knowledge across the life-cycle stages and 
organizational boundaries. 

The aim of the workshops is to clarify and elaborate the concepts of knowledge intensive 
design and CAD by providing an international forum for mutual discussions and exchange of 
opinions of experts of the field. The first workshop, held at the Helsinki University of 
Technology, Espoo, Finland in September 1995, focused on exploring the concept of 
knowledge intensive design as a part of knowledge intensive engineering activities. The 
second workshop, held during September 16-18, 1996 at the Camegie-Mellon University in 
Pittsburgh, PA, USA, examined architectures and methodologies for "knowledge intensive 
CAD" based on the results of the first workshop. A third workshop focusing on prototype 
knowledge-intensive engineering systems, experiences gained from their application, and 
future directions of research is planned for 1998 at the University of Tokyo. 

All in all, 20 papers were presented at the workshop, of which 17 were accepted for this 
volume after a review. The scope of the accepted papers covers the following important 
topics of knowledge intensive CAD: 

• Architecture for knowledge intensive CAD 

• Methodologies for knowledge intensive CAD 

• Design knowledge representation 




Knowledge intensive design for the life-cycle. 



The selected papers provide a vivid discussion on many other themes of interest in 
knowledge intensive CAD, such as knowledge systematization and organization, design 
process models, design knowledge sharing between individuals, teams, and organizations, 
design knowledge management, and evaluation of tools and methodologies for knowledge 
intensive CAD. 

Together with the proceedings of the first workshop, the volume presents an overview of 
an important novel area of research for researchers, graduate and postgraduate students, 
system developers of advanced computer-aided design and manufacturing systems, and 
engineers involved in industrial applications of these systems. It discusses not only theoretical 
aspects but also practical systems and experiences gained from these, and aims to provides a 
multi-disclipinary view of the subject both from computer science and engineering research 
angles. By producing the volume rapidly after the workshop itself, we hope to contribute 
effectively to the future development and application of knowledge-intensive CAD. 

As the co-chairs of the workshop and co-editors of this volume, we should like to thank 
all authors for contributing their research to the workshop and to the volume. We also thank 
the members of International Program Committee for their reviews during the preparation of 
the workshop and the volume. Last but not least, a special thanks is due to Rhonda Moyer for 
her excellent organization of the workshop, its programme, and special events. 



Martti M^tyla 
Espoo, Finland 



Susan Finger 
Pittsburgh, USA 



Tetsuo Tomiyama 
Tokyo, Japan 
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An intellectual infrastructure for 
integrating design knowledge 



Yusaku Shibata 

Nagoya University of Foreign Studies 
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PH:-\-81-5617-4-llllyFX:-^81-5617-5-1729 
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Abstract 

This paper analyzes the contradictions which hamper the collaboration of various 
stakeholders in evaluating early design concept, and defines a structural model of functional 
requirements for a team of catalytic consultants, which can facilitate self-organization of 
design knowledge and is named "SINPL-MEGANET". 

Keywords 

Architecture, catalytic coordination, design theory, evaluation, global sustainability, 
integration, knowledge, personality, purposeful action, self-organization, viewpoint 



1 INTRODUCTION 

If engineering artifacts should be reconciled with aspects of future world, the basic question is 
whether the effort toward improving the competitiveness of each company, which is the main 
item of interest in today's liberal economy, contributes correctly to the improvement of global 
sustainability. (Reich 1991, Yoshikawa 1993) The design process is a central research issue in 
responding to this question, which requires a change in the context of design from a short 
term market oriented industrial Product Realization Process (PRP) to a longer term global 
societal Artifact Utilization Process (A UP). This change implies that we must learn to design 
artifacts while concurrently, not only designing the manufacturing system, but also planning 
for the associated socio-technologi^ system in which the artifacts will be utilized during 
their life-cycles. It inevitably extends die concept of design teams from business-oriented 
"cross-functional" teams to intellectually "multi -cultural" teams of sociologists, economists, 
scientists, engineers, business people, lawyers, theologians, and no doubt others, for whom 
the key design issue will be in the evaluation steps of guided iteration. (Dixon 1993) It also 
necessitates extending the concept of enterprise to the extended enterprise or the "Global 
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Web" consisting of "Symbolic Analysts". (Reich 1991) 

In response to these challenges, the call for papers of the second workshop on "Knowledge 
Intensive CAD" (KIC-2) reads: 

'Due to the increasing concern about global environmental issues and rapidly changing 
economical situation worldwide, design must exhibit high performance not only in qu^ity 

and productivity, but also in life-cycle issues, including extended producers liability The 

concept of 'knowledge intensive engineering advocates that intensive life-cycle knowledge 
regarding products and design processes must be incorporated in the center of the CAD 
architecture. The concept focuses on the systematization and sharing of knowledge across the 
life-cycle stages and organizational boundaries." 

From 1953 to 1991, the author had been engaged in artifacts engineering activities, initially 
as a manager of steam turbine design engineering and later as a senior systems researcher of 
large scale artifacts development process, such as alternative energy systems and new 
transportation systems, both at a diversified manufacturing company named Hitachi, Ltd. 
From 1991 to 19% as a univeraty professor and a member of an international task force, he 
has analyzed his life-long experience and synthesized the result into a concept of intellectual 
infrastructure for integrating design knowledge as described in this paper. 



2 CONTRADICTIONS 

As quoted above from the call for KIC-2 papers, "the concept (of knowledge intensive CAD) 
focuses on the systematization and sharing of knowledge across the life-cycle stages and 
organizational boundaries." In other words, the "knowledge intensive CAD" should assist 
various practicing managers and professionals in systematizing and sharing knowledge 
required to plan and evaluate the Artifact Utilization Process, especially at the initial stages of 
systems development However, design knowledge can be integrated not only by CAD 
systems, but also by the participation of people with various cultural backgrounds, who have 
very different types of personality and hence, viewpoints. Thus, design is a social process as 
well as an engineering process. 

It should be noted that bringing various specialists together does not insure that knowledge 
about making design decisions will also be available. A distinction must be noted between the 
specialist's analytical knowledge of a life-cycle issue and the practitioner's integrative 
capability for creating and modifying early design concepts so that the life-cycle concerns are 
resolved. One of the most crucial elements in this process is the ability for groups to exchange 
models, data, information, and knowledge. For this to happen, the participants must 
synthesize and formalize much of the knowledge that is currently shared informally. (Finger 
1993, Reich,Y. etal. 19%) 

A reason for our failure in Artifact Utilization Process is the lack of understanding and 
agreement about the contradictions which hampered the integration of and the consensus 
building between various viewpoints into deeply structured, easily adaptable and 
comprehensive conceptual models. Figure 1 shows a relational structure of obstacles which 
was identified originally in the development of new energy technologies but later found to be 
applicable as a generic structure to other collaborative systems developments. (Shibata 1984, 
1993) In order to integrate various systems development activities across the life-cycle stages 
and organizational boundaries, we should strive to achieve a pro-active, aware extended 
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enterprise which is able to act in a 
real-time adaptive mode, 
responsively to the societal needs in 
a global way, and to be resilient to 
changes in the technological, 
economic, and social environment 
Therefore, the enterprise 
integration, or the objective of 
knowledge intensive CAD is 
strategic as well as technical. 

For example, the IFAC/IFIP 
(International Federation of 
Automatic Control and 

International Federation for 

Information Processing) Task Force 
on Architectures for Enterprise 
Integration, of which the author is a 
member, early recognized that a 
single, universally accepted 
architecture would be a major contribution to the field of enterprise integration. However, 
although the group first tried the path of finding an acceptable candidate from among those 
currently available and then extending it as necessary for their purpose, they have failed in 
this for political rather than technical reasons and resolved Aat only requirements and 
definition of a new architecture should be developed from the best characteristics of the set of 
existing architectures being studied by the Task Force. (Williams and Li 1995) 

Having accomplished this target, a next step of the Task Force is the development of the 
Enterprise Integration Community that will use and expand the requirements and the 
definition of the new architecture. Another next step is to create an infrastructure composed 
of Web Sites in the USA, Australia and Europe to promote the enterprise integration and to 
refine the Generalized Enterprise Reference Architecture and Methodology (GERAM). "Such 
an electronic community can increase in scale only if the community shares its resources to 
build continually on the work of each participant not only for the creation of architectures for 
enterprise integration but also for the infrastructure itself. ...In systematizing the knowledge 
about the life-cycle of manufacturing enterprises, it is essential to keep in mind the purpose 
for which the knowledge is being acquired. (Finger 1993, italics paraphrased)" 

Thus, the goal of knowledge intensive CAD should be threefold: to provide information and 
tools for knowledge intensive design, to assist the transformation and integration of 
enterprises into the extended or virtual enterprises, and to develop and maintain a new 
intellectual infrastructure for enterprise integration, composed of both human and electronic 
communities. 




Figure 1 Relational structrue of obstacles in 
collaborative systems development. (Shibata 1993) 



3 KNOWLEDGE AND PURPOSEFUL ACTION 

Curiously enough, we have been unsure about design theory. We have argued whether there 
could be a theory of design, what form it would take, and how it would relate to practice We 
have never resolved these issues to the satisfaction of our professional community or even to 
the satisfaction of those, mainly in design education, who worry about the state of theory in 
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design. The recognition that the traditional design theory might be wrong came through the 
widening gap between academic knowledge of scholars and action of practitioners. On the 
other hand, invariably at the core of professionalism is the assumption that professional action 
is and should be guided by knowledge. This professional knowledge, however, in contrast to 
academic knowledge, is primarily derived from action which is in no sense neutral- it is 
grounded in intentions or aims of the actor. Thus, acts of design belong to the category of 
behavior called teleological, i.e., "goal seeking" behavior. (Ozbekhan 1974) 

There are two senses of design, one that we acknowledge and one that generally we do not 
acknowledge. Most readily, design is understood in terms of tangible things or shape, for 
example automobiles, computers, clothes, furniture etc. We are less likely to use the word in 
its process meaning -putting concepts and ideas into material action, requiring the deep and 
often tacit knowledge-between individual s-goes largely unac knowledge. However, design 
in its planning meaning is, interestingly, the first meaning of the word in the Complete 
Oxford English Dictionary. The effect of this category mistake in design is to make the 
planning sense of early design concept silent, hence to place a ghost in design process, which 
defies explanation and hampers deep understanding of design process and hence, of 
underlying contradictions. (Ryle 1949, Koestler 1%7 and Dumas 1993) 

Since our goal is to improve the design process of artifacts, we must systematize the 
knowledge in such a way that it is usable by designers to aid themselves in making design 
decisions. "This knowledge is at present the kind that has been accumulated within companies 
and acquired through systematized experience yet. It should now be systematized through 
post-competitive research. This empirically acquired knowledge, as already stated, is created 
through competition by companies; the art of creating it is known theoretically, as abduction 
(Y oshikawa 1992). At present, there is virtually no field of research or researchers devoted to 
abduction itself What is needed now is to set this act as a topic of study and to organize post- 
competitive research that will involve various studies including the development of new 
research technique. (Y oshikawa 1993)" 

Bolan (1980) has already explored the gap between two kinds of knowledge— academic and 
professional, and the resulting chaan between knowledge and action. In his paper, after 
examining the distinction between the logic of scientific knowledge and the logic of practice, 
he analyzes, as shown in Figure 2, the practitioner (X) as a "self -in-situation," suggesting that 
designing episodes are analogous to dramas, and reflect the existing of the designers (X) in 
scenes with constituent others (Y and Z), each of whom mutually constructs a performance, 
conforming in some degree to the symbolic codes and norms of the situation. 

Figure 2 attempts to describe the realm of consciousness that is guiding the practitioner. He 
apprehends a situation and makes judgments which lead to a series of assumptions concerning 
self, others, and circumstances. The full dimensions of a scene, as actually presented to us, 
enter into our consciouaiess, and we screen them with our various sense faculties-some 
features high-lighted, others become part of a background. Thus, we each operate with very 
different sensitivities and viewpoints. In this connection, personality types of practitioners (X, 
Y and Z in Figure 2), as "selves-in-action", will be considered in the next section. 



4 PERSONALITIES AND VIEWPOINTS OF PRACTITIONERS 

As described in the previous section. Figure 2 "depicts the professional episode. The term 
'episode' is defined to include all of the persons involved, the situations or scenes involved, 
and the interactions of persons and settings as they are focused on a specific problem or 
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Figure! Elements of the professional episode. (Bolan 1980) 
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intention. A designing episode is conceived as consisting of a series of situations and scenes, 
not unlike a drama. However, there is no master playwright assumed; such episodes are more 
analogous to improvisational theater. There is no ultimate determinism implied; the 
participants are relatively free to define their own actions and make their own choices. Some 
episodes may be confined to a single scene, some may extend to many scenes of very diverse 
character. What binds them togetiier into a single episode is the intend onality or problem 
orientation of the participants. (Bolan 1980)” 

Because the beneficiary of knowledge intensive CAD is design teams composed of "multi- 
cultural” professional s-for whom the key design issue is in the evaluation steps of early 
design concept, the CAD system must be understandable and usable by the multidisciplinary 
participants with various viewpoints in dynamically changing situation as described above, in 
addition to a technical correctness and a practical comprehensiveness. In other words, it 
should be developed and maintained based upon proper understanding of predicaments 
confronting multi -cultural participants under contradictory situations, or based upon a 
reasonable framework of designers' evaluation. 

Mitroff and Kilmann (1975) have suggested a framework whereby the personality types 
which underlie various modes of evaluation may be identified and thereby themselves be 
evaluated Their paper made clear why there were no evaluation frameworks which had 
attempted to combine these various personality types into a coordinated whole. The difficulty 
for them is how to reconcile radically distinct, and sometime hostile, psychological 
viewpoints and exchange models and knowledge for integration. 

The personality typology suggested by Mitroff and Kilmann was "that of C. G. Jung. The 
Jungian typology was used for two reasons: (1) the typology can be directly related to 
different styles of doing technological evaluation; and hence, it allows us to compare these 
styles in an interesting manner; (2) the Jungian typology does not prescribe one of the four 
major personality types as superior or inherently better than any of the others but instead 
points out that each type has its major strengths as well as weaknesses. 

For the purpose of this paper, two particular dimensions of the Jungian typology are of 
special importance. The first dimension corresponds to the kind of 'input-data' an individual 
characteristically prefers to take in from the outside world. The second dimension 
corresponds to an individual's preference for the kind of 'decision-making process' that he 
characteristically brings to bear upon his preferred kind of input -data. 

According to Jung, individuals can take in data either by sensation (S) or by intuition (N) 
but not by both simultaneously. On the other hand, there are two basic ways of reaching a 
decision: thinking (T) and feeling (F). Combining the two data input modes (S and N) with 
the two decision making modes (F and T), as shown in Figure 4, results in the following four 
types:" 



(ST) sensation-thinking (technology oriented), 

(SF) sensation-feeling (organization oriented), 

(NT) intuition-thinking (concept oriented), and 
(NF) intuition-feeling (culture oriented) . 

However, by the notion of different "types", Jung does not 
mean to imply there are literally "four basic kinds of people 
and that each person is one of these and one only". Rather, he 
merely means to imply that these four types help us to come to 
grips with the elusive problem of handling different styles of 



(N) 


Intuition 


NT 


NF 


Thinking 


(F) 


CT) 


Feeling 


ST 


SF 


Sensation 


(S) 



Figure 4 Personality types. 
(Mitroff etal. 1975) 




An intellectual infrastructure for integrating design knowledge 



9 



behaving With this condition attached, followings might be typical viewpoints of various 
personality types on the Artifact Utilization Process. (Mitroff et 1977) 

4.1 ST Type (technology oriented) 

"ST types generally tend to prefer, and hence to generate, ideas which are highly detailed and 
specific and which overwhelmingly deal with technical issues in an impersonal way. In a 
word, ST's are problem-solvers, i.e., they prefer to work on very concrete, very specific, 
already-defined pre-existent technical problems. They are neiAer problem-finders nor 
problem-generators, nor are they especially sensitive to personal, moral, or value issues. 
Indeed, one of the strong defining characteristics of ST's is that they believe that moral or 
ethical issues are either meaningless in themselves or devoid of substantive precisely because 
they cannot be formulated precisely, impersonally, and technically, or at least not to the 
satisfaction of ST's." For example, 

"Since many of these problems (modem evils) result from the use of existing technologies, 
the solution to these problems will depend in large part on the development of new 

technologies in addition to policies which encourage behavioral change (Although) 

individual technological development for new types of artifacts,... .is necessary, including 
design, production, operation, maintenance, reclamation, reuse, recycling, and 
discarding. ...we point out that knowledge systematization over life cycle stages is the most 
urgent ta^. (Tomiyama 1993)" 

4.2 NT Type (concept oriented) 

"NT Types generally tend to prefer ideas which are highly global, broad, far-reaching, and 
which deal with a wide range of overwhelming technical issues in an impersonal manner. In a 
word, NT's are problem-inventors, problem-finders, or problem-generators. They prefer 
working on the new and innovative to the tried and true. Like their ST counterparts, they tend 
to be insensitive to personal, moral, and value issues. This is not so much because they feel 
moral issues are meaningless unless they can be formulated in detailed specifics (indeed, 
unlike ST's, they are not interested in the details of issues, but rather with their over-all or 
holistic features); rather, it is because NT's are more interested in technical ideas than they are 
in people." For example, 

"We cannot build it yet But already we can specify the 'postmodern' factory of 1999. Its 
essence will not be mechanical, though there will be plenty of machines. Its essence will be 
conceptual-the product of four principles and practices that together constitute a new 
approach to manufacturing. (Drucker 1991)" 

4.3 NF Type (culture oriented) 

"like NT's, NFs also tend to take a global approach to issues and problems. This is due to the 
common N or intuitive side of their person^ity which they share. The essential difference is 
that where NT's are primarily interested in treating all matters from an impersonal or 
technical point of view, NFs are primarily interested in treating them from a personal, human, 
moral, and ethical point of view. For NFs people are the overriding concern. Like NT's, NFs 
are also problem-generators. However, the difference is (again) that NFs are problem- 
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generators of people problems. All problems are, for them, in the first and last resort people 
problems. " For example, 

'The liberal economy must begin to move toward seeking optimum suitability by itself 
because it is clear that today's liberal economic system is not optimal, at least from the 
standpoint of global reduction of waste....Intelligent Manufacturing Systems (IMS) is a 
technical cooperation for the ideal theory of manufacturing that transcends cultural 
differences....IMS is a dream, and please join us for realizing our dream. (Yoshikawa 1993)" 

4.4 SF Type (organization oriented) 

"SF's are like ST's in their strong liking and preference for specificity, detail, and well- 
formulated problems. Like ST's, they tend to be problem-solvers rather than problem- 
generators. They differ, because of the F component of their personality, in their preference 
for people. For SF's, as for NF's, people are always the overriding concern. The main 
difference is that where NFs like people in general humanity, SFs like people in particular, 
i.e., their immediate circle of friends, associates, neighbors, etc. Anything which fails to relate 
directly and specifically to their immediate circle of friends is either irrelevant or 
meaningless. Another way to put it is to say that they find abstract, theoretical, and scientific 
solutions utterly cold, impersonal, and meaningless." For example, 

'The future will neither belong to 'big' and 'intelligent' technology, nor to 'large' and 
'powerful' bureaucracies, but to human organizations that will be able to set up human goals 
shared by the largest as possible fraction of people throughout the world, and to achieve them 
by using knowledge and technology, in the public and general interest. (Petrella 1989)" 

4.5 Integrating Different Personalities and Viewpoints 

As described above, the key research issue of Artifact Utilization Process lies in the 
evaluation steps at the early planning phases. But, it should be clear by now that in integrating 
design knowledge and activities, we are dealing with very different types of individuals who 
find extreme difficulty in appreciating one another. However, a point of particular interest is 
the fact that all of four Jungian types are valuable and needed in planning, but at different 
stages of planning. Thus, N's are better suited at the strategic phase of planning, whereas S's 
are better suited for translating strategic ideas into operational plans. Both need as well as 
depend upon one another. Therefore, our next task is to find a proper framework and a 
calalytic coordination system for a self-organized integration of design knowledge and 
activities, which will be dealt with in the following sections. 



5 A FRAMEWORK FOR INTEGRATING DESIGN KNOWLEDGE 

5.1 Architectures and Frameworks in Integrating Design Knowledge and Activities 

The integration of design knowledge requires inevitably the integration of various engineering 
activities within an extended enterprise, which does not occur without a fundamental 
transformation in business structure and process. (Inagaki 1993) The primary challenge for 
the enterprise is to maintain relevance in the face of a dynamic marketplace and dramatically 
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changing technologies. When the transformation is not effected by ourselves, the result is 
early obsolescence and a control of our destiny by someone else. "Social architecture is the 
art of designing and building a complex organization. Welch characterizes his vision for the 
next century with the word 'boundarylessness'. ’Old Way' organizations were all about 
boundaries and compartmentalization and chains-of-command. The new organization would 
be free of these increasingly nonproductive strictures. Information would flow freely across 
functional and business boundaries from where it was developed to where it was needed. 
(Tichy and Sherman 1994)" 

James G. Nell (19%), Convener of the International Standards Organization(ISO)/ 
TC184/SC5AVG1 (Working Group 1: Modeling and Architecture) has proposed followings as 
the WGl definition of architecture and framework 

Architecture, or Enterprise -Reference Architecture 

The body of classified knowledge for designing, building, operating, and modeling 
enterprises. The architecture contains guidelines and rules for the representation of the 
enterprise framework, systems, organization, resources, products, and processes. 

Framework 

The delineation of the components and viewpoints (for example: activity, information, and 
process capability) that comprise a specific enterprise representation, the interfaces, and 
the relationships that exist between the respective viewpoints of the components. 

According to Nell (19%), a shared -meaning element between architectures and frameworks 
is an arrangement "The life-cycle activities of a system development during which an 
arrangement becomes available, occurs toward the end of the system-definition activities and 
toward the beginning of the physical-realization activities. This is where the physical 
arrangement aspect of architecture and the structural arrangement aspect of framework 
converge Given this, to define framework one may assume, therefore, that there exists a 
relevant architecture. This architecture, among other things, define a framework— the limiting 
structure and its supporting members-of the thing being built The framework is the defining 
real-world manifestation of a portion of the abstract notion of architecture. A framework is a 
basic structure; a frame of reference, or a systematic set of relationships. The framework does 
not include the art, science, style, and methodology required to develop the system, only the 
scope of the system and an arrangement of die components, standards, or principles 
governing behavior, thoughts, actions. ...The choice of framework depends on the purpose of 
the endeavor. Thus, architectures supply the body of topical facts and knowledge, and 
frameworks define the scope, the interface and the components." 

The IFAC/IFIP Task Force on Architectures for Enterprise Integration has found that the 
concept of architecture for enterprise integration is beginning to have coherence and has 
principally four main components: 

•GERA (Generic Enterprise Reference Architecture); 

#GEMs (Generic Enterprise Models); 

#GEEM (Generic Enterprise Engineering Methodology); 

•GEMT&L (Generic Enterprise Modeling Tools and Languages), 
and supporting sub-components as shown in Figure 5, which were named GERAM 
(Generalized Enterprise Reference Architecture and Methodology) as a collective term. 
ISO/TC184/SC5/WG1 is now starting to discuss GERAM as a new -work-item proposal. 
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In addition, the task force believes that the same architecture can be used to describe not 
only the enterprise integration process itself, but also three other related enterprise activities 
as well: 

# Strategic enterprise management process life cycle; 

# Enterprise engineering/integration process life cycle; 

# Enterprise life cycle; 

# Product life cycle. 

"Such a concept of universal usage of the principles of enterprise reference architecture 
applicability in all areas of human endeavor today has major ramification on the importance 
and potential future use of the result of the IFAC/IFIP Task Force's work. (Williams 1994)" 
For the moment, such a development remains open ended. Nevertheless, its overall 
configuration, its main concepts and phases, are now sufficiently general so that one can 
describe and discuss them without specific cases. The purpose of this paper is precisely to do 
that in the area of Artifact Utilization Process life-cycles and to propose a new framework, as 
defined below, for the purpose of enterprise extension and transformatioa 
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5.2 Requirements for a Framework for Artifact Utilization Process Life-Cycle 

Quoting again and paraphrasing Nell’s definition of framework as described in the previous 
sub-section, "the framework should be the defining real-world manifestation of a portion of 
the abstract notion of GERAM. The framework should be a basic structure of artifact 
utilization process life-cycle; a frame of reference, or a systematic set of relationships. The 
framework should not include the art, science, style, and methodology required to develop the 
system, only the scope of the artifact utilization process life-cycle system and an arrangement 
of the components, standards, or principles governing behavior, thoughts, actions.... The 
choice of framework depends on the purpose of the endeavor, which is an enterprise 
transformation for Artifact Utilization Process." 

In developing a framework for Artifact Utilization Process life-cycle, we should consider 
carefully Bolan's suggestion on the professional episode, especially the roles of actors as 
"selves-in-action" as shown in Figure 2. For example, in order to be a useful guidance system 
in practice, four components of GERAM as shown in Figure 3(A) should be interfaced with 
the activity model as shown in Figure 3(B), which was derived from Figure 2. From the same 
standpoint, the author is proposing a framework consisting of four components as described 
in the following sub-sections: 

•structural Meta-Model (SMM) for GERA; 

•Holonic Decentralized System (HDS) for GEMs; 

•Simplified Normative Planning (SINPL) for GEEM; 

•Mega-Network (MEGANET) for GEMT&L. 

5.3 Structural Meta-Model (SMM) for GERA 

Pilot case studies of CIMOSA (CIM Open System Architecture), which is one of three 
candidate architectures of GERAM, have shown that the most striking potentials today lay in 
the field of organization. Starting from the traditional Tayloristic understanding of the 
enterprise, many iterative steps were necessary to arrive at the changement of thinking, which 
needed a period of learning by doing and some doubts and crises under way for all of the 
team. The only recently defined constructs for the organization view proved to add an 
important amendment to the architecture that so far has been very much information 
technology oriented. At present, specific tools to apply enterprise models unfortunately do not 
exist They will simplify modeling and augment user acceptance. (Katzy et al. 1993) 

Above mentioned issues require more simplified modeling tools, especially laying emphasis 
on organizational redesign. Managers and professionals, who are engaged in enterprise 
transformation, must overcome many obstacles, both technical and nontechnical, as shown in 
Figure 1. Their actions will possibly become more effective if relevant information and 
guidelines are timely offered to them based upon some reliable design theory. However, we 
are unsure about a reliable design theory because, although there has been increasing criticism 
of the ruling design theory, no set of concepts has emerged that convinces a majority of 
practitioners that the new paradigm of design Aeory has been found. 

In the following sections, an emerging design paradigm is leading to the redefinitions of 
design process model, in which Figure 1 will suggest relations between the enterprise and its 
environment, and will be utilized as a graphical expression of a framework, nam^ Structural 
Meta-Model (SMM). SMM includes die enterprise model implicidy as a subsystem which 
will be a Holonic Decentralized System (HDS) and dealt with briefly in the next sub-section. 
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5.4 Holomc Decentralized System (PDS) for OEMs 

The enterprise transformation can not be imposed as a rigid regimen. It is dynamic, built 
around the requirements of autonomous subsystems, continuously evolving and responding as 
the situation changes. Throughout the entire process, cooperation among all participants in the 
decision making stages and integration of each sub^stem's requirements into the process are 
essential factors. By identifying in advance the interfaces of extended enterprise as it is 
shaped by and affects the different parts of Artifacts Utilization Process, we can improve the 
efficiency and the effectiveness of transformation process, which will permit operations to be 
made concurrently. 

Some 25 years ago, Koesder (1989) has proposed a word "holon" to express a similar 
concept on social structures and functions. The word is a combination from the Greek holos 
(=whole) with the suffix on, which suggests particle or part. He points out that in this system, 
the subwholes/holons are autonomous self-reliant units, which have a degree of independence 
and handle contingencies without asking higher authorities for instructions. Simultaneously, 
holons are subject to control from multiple higher authorities. The first property ensures that 
holons are stable forms, which survive disturbances. The latter property signifies that they are 
intermediate forms, which provide the functionality for the bigger whole. Kurosu of Toyota 
(1992) wrote that the essence of Toyota production system is the holonic system which is 
defined as "a system composed of essentially distributed elements which act and cooperate 
with each other based on autonomously selected individual norms in order to achieve 
individual objectives”. HDS is proposed as a model system and describes the integrated 
enterprise as it is going to function. 

5.5 Simplified Normative Planning (SINPL) for GEEM 

As described in section 3, the discussion of design theory appears to be stuck and in need of 
renewal It is stuck in that the criticisms of the rational design model and proposals of 
alternatives to it continue to repeat the same arguments and draw familiar ideas. Meanwhile, 
indifference and hostility of practitioners to researchers of design theory grow. This suggests 
that we need to simultaneously pursue a search of new framework for cooperation between 
practitioners and researchers and a research of design model building itself. 

Simplified Normative Planning (SINPL) as shown in Figure 6 seems to be one of 
methodologies ideally suited for catalyzing a self -organized modeling process. (Shibata 1992) 
The goal of SINPL is primarily to define the framework of design or to me ta -design. The 
difficulty of meta-design will be alleviated to some extent by using a conceptual framework 
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Figure 6 Five steps models of design process by various authors. 
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(meta-rule) of SINPL which consists of design process (meta-process model), problem 
structure (meta-problem model) and players team organization (meta-role model). A special 
feature of SINPL is that it does not start from a given problem but from a desirable future 
vision or a norm, from which the name SINPL is derived. Also S-I-N-P-L explains five 
workshop steps as described below: 

1. Forecasting desirable future (process) and vision Scenario (structure) 

2. _Lisight of contradictions (process) and problem structure (structure) 

3. New idea proposal (process) and Normative objectives (structure) 

4. Strategic Planning (process) and strategic patterns (structure) 

5. Action proposal (process) and Launching tactics (structure) 

The chief advantage in using SINPL for complex problem solving is that they provide a 
mode of experimentation with alternative strategies and tactics in a constantly changing 
environment The fluid nature of a meta-design approximates the uncertainties encountered in 
a real situation. The artificially controlled contexts, which the conceptual framework of a 
meta-design imposes, build into it certain relationship between the decisions made by some of 
the players and the response of other stakeholders. But these relationships are unknown 
initially to the players and are only revealed as the meta-design proceeds. So the outcome of a 
particular decision or strategy has immediate effects, thereby providing data for analyzing and 
evaluating the selected course of action with neither die time lag nor the potentially 
irreversible consequences of a decision in the real world. 

5.6 Mega-Netwoiit (MEGANET) for GEMT&L 

The artifact utilization and enterprise transformation process is a highly sophisticated, 
multidisciplinary management, design and implementation exercise during which various 
forms of descriptions and models of the target process need to be created. In addition to a 
technical correctness and a practical comprehensiveness, GEMT&L (Generic Enterprise 
Modeling Tools and Languages) should be understandable and usable by the communities 
targeted Quoting and paraphrasing Nell’s definition of framework (1996) again, "the 
framework should be the defining real-world manifestation of GEMT&L-a portion of the 
abstract notion of GERAM". Two main objectives of the framework for GEMT&L are for all 
participants to understand the real world meaning of artifact utilization and enterprise 
transformation process, which will not start spontaneously with no external intervention and 
coordination. The capacity to sustain such massive coordination over a long period of time 
and retain the stability of policy throughout the process, is the basic requisite of complex 
problem solving. Sustained drive and energy, as well as the creative catalytic leadership style, 
are scarce skills within our society and the tiiird objective of the framework 
Thus, a new conceptual and essential scheme to aid this endeavor is a framework named 
MEGANET (Mega-Network), which means "a network to support formation of conceptual 
strategy or policy" and is a network or a global web of extremely creative catalytic 
consultants and can be utilized to help managers and professionals solving obstacles in the 
enterprise transformation process. (Shibata 1984) 

However, for sometime to come, the framework can not be a guidance system but should be 
a social learning environment because the barriers between professionals cannot be removed 
by a framework and/or advice from outside consultants. The main requirement is that the 
persons concerned with interprofessional collaboration become so well acquainted with each 
othefs viewpoint that the mutual misunderstanding of specialists is replaced by overlapping 
views. Therefore, an essential task for the framework in this endeavor is the creation of 
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Figure? Interrelationships between MEGANET and other components of a framework 
forGERAM 

learning environment and process which allow specialists and managers as well as customers 
to self-organize a shared framework of system appreciation and facilitate the renewal of 
design theory. 

Thus, MEGANET is like a catalyst because it guides the change process with no external 
power or authority. It is also similar to a gene. MEGANET itself is autonomously 
decentralized and has all fundamental functional units necessary for the target systems. In this 
meaning, it is a model which has a good communication capability with the client. However, 
the target system is not a physical, chemical nor biological phenomenon, but is a social 
phenomenon composed of many people and can creatively evolve forever. What guarantees 
this evolution is an extraordinaiy capability of the system to communicate with surrounding 
environment Another capability which is indispensable to maintain the unity and harmony of 
the system is an attractive common vision which should be, again, self-organized. 

From the preceding discussions, it is clear that MEGANET-the concepts of which were 
originally proposed by Friedmann (1973) and Williams (1973) and modified by Shibata 
(1984)— must play a variety of roles with respect to the obstacles facing transformation as 
shown in Figure 1. However, because the obstacles are highly interdependent, the framework 
of MEGANET cannot be such that there is only one function for each obstacle. Rather, the 
framework that should emerge is a mix of functions to deal with multiple obstacles and 
interrelationship at the various levels of management as shown in Figure 7. 



6 CONCLUSION: TOWARD AN INTELLECTUAL 
INFRASTRUCTURE FOR INTEGRATING DESIGN KNOWLEDGE 

Based upon his life-long experience as a practicing design engineer at a manufacturing 
company and a researcher at universities, the author believes that a framework composed of 
four components as described above is an insightful conceptualization of enterprise 
transformation for artifact utilization process. It both highlights critical issues and guidelines 
for integrating extended enterprise where autonomously decentralized organizations and 
individuals should be interface. It further suggests group processes and agenda formats 
which guide each step of enterprise transformation. 

From a number of experimental and preliminary applications of this framework, which was 
named SINPEMEGANET, the author is convinced of its practicality and power, but also 
believes that considerable skill is required to activate an ongoing process of collaboration. For 
example, practitioners often need preparatory training in order to 




An intellectual infrastructure for integrating design knowledge 



17 



•Cognitively internalize the design process as a discrete series of workable steps, 
•integrate diverse participants and ideas in each step, and 
•Transfer and apply the obtained findings to their daily problems. 

Further in addition, our experience suggests that timely supports from outside network of 
extremely creative catalytic consultants are indi^nsable to sustain such a massive 
coordinative drive and energy over a long period of time. Similar networks are being built by 
many organizations, including the Enterprise Integration (El) Community by IFAC/IFIP Task 
Force on Architectures for Enterprise Integration, of which the author is a member. These 
electronic and human communities will increase in scale, number and quality by sharing their 
resources not only for the creation of architectures for enterprise integration but also for the 
infrastructure itself. (Finger 1993) 
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Abstract 

Large engineering design projects involve many different disciplines each with their own area of 
concern and expertise. A large amount of information (design data and knowledge) is processed 
and exchanged among such disciplines, and even within each discipline. Traditional computer 
environments cannot cope easily with such complex situations. Hence new approaches must be 
sought. This paper presents an experimental design environment organized as a population of 
asynchronous cognitive agents. Issues about the general architecture, the internal structure of an 
agent and inter-agent communication mechanism are discussed. A prototype including a number 
of independent agents is then presented and demonstrated on a smdl mechanical design. 

Keywords 

Cognitive Agents, Engineering Design Knowledge, CAD. Mechanical Design. 



1 INTRODUCTION 

Large engineering design projects require the cooperation of multidisciplinary design teams 
using sophisticated and powerful engineering tools such as commercial CAD tools, engineering 
databases, knowledge-based systems, simulation systems, or other special purpose 
computational tools. The individuals or the individual groups of the design teams work in 
parallel and independently, often for quite a long time, with tools located on different sites. 
Thus, at any time, individual members may be working on different versions of a design, 
viewing it from various perspectives (e.g., electronics, manufacturing, planning), at various 
levels of details. In order to coordinate the design activities of the groups and to guarantee a 
good cooperation among the engineering tools, it is necessary to develop efficient distributed 
(eventually intelligent) design environments. Such environments should not only automate 
individual tasks, like traditional computer-aided engineering tools, but also help individual 
members to share or exchange information (design data and knowledge) and to coordinate their 
actions as they explore alternatives in search of a globally optimal or near-optimal solution. 
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Our approach to large engineering design projects is to decompose the overall project of 
designing a complex artefact into a set of different services. Such services are used by local 
teams which, in turn communicate with other teams. Typically such teams reside at different 
locations and are specialized in different aspects in the design of the product. Local teams work 
on a local network, and can also share or exchange design data and knowledge with remote 
teams via Internet. As a global policy, we do not plan to enforce a global consistency on the 
project. Each team needs a number of services, which are usually closely dependent on its 
particular engineering activities. Such services are to be assigned to agents both human and 
automatic. 

Focusing on the work of a local set of specialists, we see the need for several types of 
services, which today are solved by various engineering tools. At this level of our approach, we 
found a number of other proposals aimed at using distributed problem solving techniques for 
addressing concurrent design. Indeed, in the past ten years, a number of researchers have 
proposed to use distributed problem solving technology for concurrent design (Gero 1987; 
Sriram et al 1991; Mantyla 1995); or proposed some general architectures or platforms for 
engineering or industrial applications such as SHADE (McGuire et al 1993), SHARE (Toye et 
al 1993), ARCHON (Jennings, Corera, and Laresgoiti 1995; Cockbum and Jennings 1995), 
SINE (Brown et al 1995), MIT DICE (Sriram et al 1989; Sriram et al 1992), DARPA DICE 
(Reddy et 1993; Londono et al 1992), KIEF (Tomiyama et al 1995), ICISs (Papazoglou et al 
1992), Synchronous Group Applications (Tou et al 1994), PACO (Demazeau 1993) and 
OSACA (Scalabrin and Barthes 1993); or developed some agent-based systems such as PACT 
(Cutkosky et al 1993), First-Link (Park et al 1994), Next-Link (Petrie, Cutkosky, and Park 

1994) , Anarchy (Quadrel et al 1993), ACORN (Coyne et al 1994), ATOS-1 (Jones et al 1995), 
ABCDE (Balasubramanian and Norrie 1995), SiFA systems (Brown et al 1995; Dunskus et al 

1995) , CONDOR (Iffenecker 1994); some multi-expert systems such as DESIGN-KIT 
(Stephanopoulos et al 1987; Sriram et al 1989), IBDE (Fenves et al 1990), GUIDE (Morse 
1990), CE Testbed (Brandt and Petro 1992; Londono et al 1992), MATE (Saad and Maher 

1996) , ANAXAGORE (Trousse 1993), EXPORT (Monceyron and Barthes 1992), ARCHIX 
(Thoraval and Mazas 1990), CAAD (Branki and Bridges 1993), some specific computer tools 
for inter-agent communication such as KQML (Finin, McKay, and Fritzson 1992), COOL 
(Barbuceanu and Fox 1995), ToolTalk'^ (Frankel 1991), and (Populaire et al 1993), and some 
frameworks for inter-agent control (Van 1990; Lee, Mansfield, and Sheth 1993; Quadrel et al 
1993; Boissier 1993). 

The various approaches can be divided into two types of cooperative design systems 
according to their organization: multi-expert systems (based on a blackboard structure) and 
multi-agent systems. In a multi-expert system each specialist (usually called a knowledge 
source) has access to the blackboard where all information is posted and made available to all. 
In what we call a multi-agent system each agent is independent and has its own representation 
of the situation independent from that of other agents. In the first case, one normally uses a 
shared memory; in the second case, agents can be moved freely to independent machines, 
provided that they can communicate using messages. It is more than a simple difference in 
implementation. 

Blackboard has been and still is a very popular architecture for building cooperative design 
systems. Several important design systems have been built using this architecture. IBDE 
(Fenves et al 1990) was established at CMU as a testbed for exploring integration of various 
specialists and the possible control strategies. GUIDE (Morse 1990) was also developed at 
CMU to test the problem of conflict resolution. KIEF (Tomiyama et al 1995) is a computational 
framework for knowledge intensive engineering developed at the University of Tokyo. It puts 
more emphasis on the knowledge acquisition problem. ANAXAGORE (Trousse 1993) was a 
joint project between the INRIA Research Institute and Aerospatiale. It involved the cooperation 
between a knowledge-based system and specialized CAD tools and was used to study multi- 
representation and multi-configuration problems. ARCHIX (Thoraval and Mazas 1990) was a 
joint project developed at Renault, University of Paris VI, and University of Technology of 
Compiegne, to study the propose and revise strategy for designing front wheel drive-trains of 
cars. EXPORT (Monceyron and Barthes 1992) was a joint project between University of 
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Technology of Compidgne and the Ministry of the Sea in France, and was implemented to 
integrate a number of existing tools used in the preliminary phase of harbour design. It included 
a number of specialists like breakwater design, residual wave motion computation, silt motion, 
etc. It emphasized the coupling of symbolic and numeric approaches. CAAD (Branki and 
Bridges 1993) was a joint project between Glasgow Caledonian University and University of 
Strathclyde in Scotland. It used a multi-blackboard architecture for distributed design 
environment. Such an architecture dispatches information over several blackboards, and each 
blackboard contains a relatively small amount of information. MIT DICE (Sriram et al 1992) is 
a complex blackboard system developed at MIT for studying cooperation processes among 
engineers. Recently, MIT DICE has been developed progressively through sub-projects like 
SHARED (Wong and Sriram 1993, Wong 1993), SHARED-DRIMS (Pena, Sriram, and 
Logcher 1993). The Concurrent Engineering Research Center (CERC) was established at the 
West Virginia University as a part of the DARPA Initiative in Concurrent Engineering (DICE) 
(Reddy et al 1993). CE Testbed was a main research result at CERC in order to demonstrate the 
capabilities and benefits of the DARPA DICE technologies (Londono et al 1990). A turbine 
blade engineering scenario has been implemented using the CE Testbed (Brandt and Petro 
1992). MATE (Saad and Maher 1996) was developed at University of Sydney as a multi-user 
architecture for collaborative design in which existing applications, like CAD tools, modelling 
programs, analysis programs, knowledge-based systems can be shared by more than one 
designer. Two categories of shared workspace, shared visual representation and shared 
underlying representation, have been implemented in this project. Many other projects have also 
been developed or are being developed using a blackboard approach. 

However, although a blackboard architecture has the definite advantage of ensuring 
consistency, it has nevertheless some drawbacks: (i) the blackboard can be a communication 
bottleneck; (ii) when using a blackboard to coordinate different engineering tools, each tool has 
its own representation of the data describing the problem to solve; such a representation is often 
private to the tool, and there is no particular advantage in transferring it to a centralized location; 
(iii) during a project lifetime new tools may be introduced, changing the structure of the design 
environment, and therefore the woridng environment has often to be reinitialized; (iv) the meta- 
knowledge (knowledge about the project) is usually not recorded in the blackboard systems. 

On the other hand, in multi-agent systems, each agent builds its own model of the current 
solution by acquiring information from the other agents. This type of system needs a 
communication protocol and a message format (common language) according to which the 
requests and the responses will be formed. Each agent stores the current solution, or at least a 
part of this solution in its local fact base. Generally, in multi-agent systems, agents are 
heterogeneous and autonomous, i.e., there is no global control, the communications among 
agents can be synchronous or asynchronous, point-to-point, broadcast, or multicast, and the 
messages among the agents have a high-level semantics. 

Recently, some projects have been developed using an agent architecture. SHADE (McGuire 
et al 1994) is primarily concerned with the information sharing aspect of the concurrent 
engineering problem. SHADE demonstrated a flexible infrastructure for anticipated knowledge- 
based, machine-mediated collaboration between disparate engineering tools. It is a project 
within a larger cooperative community looking at related issues. PACT (Cutkosky et al 1993) 
was a landmark demonstration of both collaborative research efforts and agent-based 
technology. SHARE (Toye et al 1993) is concerned with developing open, heterogeneous, 
network-oriented environments for concurrent engineering. FIRST-LINK ( Park et al 1994) is a 
system of semi-autonomous agents helping specialists to work on one aspect of the design 
problem. NEXT-LINK (Petrie et al 1994) is a continuation of the previous project for testing 
agent coordination. All the previous systems were developed at Stanford. Anarchy, developed 
at CMU, (Quadrel et al 1994) is a working prototype of an asynchronous design environment 
for generating, evaluating and modifying designs of medium- and high-rise office buildings. 
The simulated annealing method was applied in Anarchy as a control strategy. ITX (Lee, 
Mansfield, and Sheth 1993) also addresses the issue of interaction control. SiFA (Brown et al 
1995; Grecu and Brown 1995), developed at Worcester Polytechnic, is intended to address the 
issues of patterns of interaction, communication, and conflict resolution. Some interesting 




22 



Part One Architecture for Knowledge Intensive CAD 



experiments were also conducted between CMU and Stanford University in particular by Finger 
in class projects with industrial problems (Reddy, Chan, and Finger 1995; Toye et al 1993). 

We are currently developing a prototype of Distributed Intelligent Design Environment 
(DIDE) (Shen and Barthes 1995b; Barthes 1995) based on an architecture called OSACA (Open 
System for Asynchronous Cognitive Agents) (Scalabrin and Barthes 1993), derived from 
previous work in the domain of robotized assembly systems (Abriat 1991). Our goal is to verify 
whether it is actually possible to build truly open systems, that is, systems for which users can 
freely add or remove agents without having to halt or to reinitialize the work in progress in any 
way. We also want to exercise the obtained prototype in order to gain first hand experience, 
first with small examples, then with larger projects. Indeed, we are interested in fine in very 
large design projects of complex systems such as an automobile, a locomotive, a harbour, or an 
aircraft. Such design projects share the following characteristics: the design requires a large 
number of individual designers or several working groups to work together, the design period 
is long, and the design is very expensive. In this case, we do not think that a multi-expert 
architecture built upon a blackboard architecture could scale up. On the other hand, developing a 
network of independent local agents looks more promising. A major difference between our 
approach and that of SHADE-based projects (PACT, First-Link, Next-Link) is in its global 
structure. Indeed, in DIDE all agents are independent and first class; in particular, there is no 
facilitator structure like in PACT. 

The rest of the paper describes our project. It is organized as follows: Section 2 presents the 
general DIDE architecture, the internal structure of a single agent, as well as the inter-agent 
communication. Section 3 describes the experimental implementation of the DIDE with a small 
mechanical design example. Section 4 gives some concluding remarks and discusses some 
important issues. 



2 A MULTI-AGENT ENVIRONMENT FOR COOPERATIVE 
ENGINEERING DESIGN 

2.1 A general architecture for design environment 

The overall organization of an agent-based architecture for design was described in the 
introduction. Several issues need to be clarified. 

The system is not intended to run automatically. On the contrary, human beings are part of the 
system. The system cannot be organized independently of the company structure. Thus, we 
assume the project will be run by a project manager, and that each local group will in turn have 
a local project manager. We are interested here in a local group. Within the local group, some 
agents will be controlled by humans, other will provide services automatically. When humans 
are in full control, then this amounts to a traditional client/server architecture. It becomes more 
interesting when some agents are actively offering services knowing the final goal, i.e., the 
agents not only reply to the requests of the other agents, but also can give some suggestions or 
advice to the current design project according to their knowledge. 

A second issue relates to the control of the design task. Apart from the project manager we 
assume no central control of the design task. Subtasks are created for answering requests as 
needed, once the work is initiated. There is no global planning neither central nor distributed. 
From this point of view, the agents are purely reactive. However, some subtasks may have 
predefined sequences (e.g., scenarios, amounting to local plans). When this is the case, there is 
no reason why such sequences should not be used. 

A third issue concerns the global consistency of the design. The consistency is kept at a 
minimum, considering that each agent has a local model of the designed device. However, in 
mechanical design it is sometimes possible to show a model of the designed product. In such a 
case, each subgroup is allowed to modify the model independently, using its own design space. 
Results are kept in different versions of a model database. Then, at each progress meeting, it is 
the responsibility of the product manager to merge all the version propositions into a unique 
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design. Of course, the environment has to support the merging process reconciliation efficiently 
(Barthes 1993). 

A fourth issue concerns the agent behaviour. We assume that all agents are connected by 
means of a network, local network or Internet. Each agent can reach any other active agent by 
means of a broadcasting message. All agents receive messages. They may or may not 
understand such messages. When they do not understand a message, they simply do nothing. 
Whenever they understand the message, then they start working on it, provided the priority of 
the message is higher than the current work they were doing. Thus, agents are multi-threaded. 
When a new agent is introduced, it is simply connected to the network. Thereafter, it receives 
messages like any other agents. 

A fifth issue is related to the legacy problem. In our design environment, an agent offers some 
specific service, usually by encapsulating a particular engineering tool. The agent interaction 
relies on three things (Cutkosky et al 1993): shared concepts and terminology for 
communicating knowledge across disciplines, an interlingua for transferring knowledge among 
agents, and a communication and control language that enables agents to request information 
and services. This technology allows agents working on different aspects of a design to interact 
at the knowledge level, sharing and exchanging information about the design independently of 
the format in which the information is encoded internally. 

2.2 Internal structure of an agent 

In our environment, agents are autonomous cognitive entities, with deductive, storage, and 
communication capabilities. Autonomous in our case means that an agent can function 
independently from any other agent. Figure 1 shows the internal structure of an agent (Ribeiro 
Gouveia and Barthes 1993). 
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Figure 1 Internal structure of an agent in DIDE. 

An agent is composed of: (i) a network interface (shaded portion in Figure 1); (ii) a 
communication interface; (iii) symbolic models of the other agents, and associated methods to 
use them (agent models in Figure 1); (iv) a model of its own expertise (internal KB); (v) a 
model of the task to be performed, or of the current context (local knowledge). 

The network interface simply couples the agent to the network. The communication interface 
of an agent is composed of several methods or functions for sending and receiving messages to 
and from other agents. A message box is used to temporarily store all received messages. 
Processing incoming mails requires two steps: (i) receiving, storing, and sorting messages; (ii) 
encoding a message content for further processing by the agent in the context of a particular 
task. Processing out going mail similarly requires encoding of the information to be transmitted, 
and actually mailing it according to the exchange protocol. The symbolic models of the other 
agents are realized by means of a knowledge base containing information about the other 
agents, obtained during interaction. The information includes an agent's name, address, and 
skills or competences. The knowledge helps the current agent to select one or more agents as 
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sub-contractors for processing tasks. The model of "own expertise" is also a knowledge base 
composed of self information such as the name, address and competences or skills. The latter 
may be methods for activating tasks corresponding to the received requests. The local 
knowledge is a knowledge base composed of the information about the global task to be 
performed. It contains some already achieved partial solutions for a particular task. 

At first, when a new agent is connected to a group of active agents, then only its 
communication interface and its own expertise contain information. The part recording facts 
about the work to be done, or the capabilities of the other agents is empty. In the case of slave 
agents (e.g., a local database. Local DB, as described in Section 3), this will not change, i.e., it 
will remain empty. In other cases, each agent must build its own image of both the work to be 
done and the capabilities of the other active agents, by extracting information from the various 
messages it receives. 

2.3 Inter-agent communication 

In general, communication can be synchronous or asynchronous, and the communication mode 
can be point-to-point (between two agents), broadcast (one to all agents), or multicast ( to a 
selected group of agents). The OSACA-based DIDE environment uses a multi-cast mode which 
can be extended to point-to-point and broadcast. In addition, DIDE allows for five simple 
actions: request, inform, announce, bid and notice. They are grouped into two categories: 
requests and assertions (REQUEST, INFORM, NOTICE); call for bids and offers 
(ANNOUNCE, BID). 

2.4 Task structure 

Task execution is initiated locally and can be done in different manners. Firstly, agents can 
broadcast information to all the other agents and then wait until some agent has computed the 
answer. In this way, the task can be carried out by several specialists of the subject, working in 
parallel (efficient only when they reside on distinct machines). Secondly, a contract protocol can 
be used, i.e., an agent broadcasts an offer describing the job to be done, waits for some time 
for submissions from the other agents, and then awards the contract to a particular agent 
according to some local criteria. Thirdly, a contract can be allocated directly to a known 
specialist. Note that although the last solution could appear to be the most efficient, a general 
broadcast allows all the agents to see the content of the request. Therefore, even if agents are 
not directly concerned by the request, they can nevertheless use part of its content to update 
their internal representation of the task being done or of their image of the expertise of the 
requesting agent. 



3 IMPLEMENTATION 

A small system has been developed for testing the basic feasibility of the project, as well as the 
possibility to encapsulate traditional tools, and to bring agents in and out without halting the 
system. 

The first version used only slave agents (no active agents) and looked like a generalized 
client/server architecture. The current version, still being developed, uses the OS ACA platform. 
Although developed as a local group, i.e., using several workstations on a local network, it has 
the capability of intergroup communication using Internet. 

3.1 Hardware and software environment 

The experimental environment is built on a network of SUN and VAX workstations. The 
OSACA platform developed in the DAI research group of University of Technology of 




Exchanging engineering design knowledge by cognitive agents 



25 



Compiegne (Scalabrin and Barthes 1993) is used for defining agents and inter-agent 
communications. Some agents are implemented as a MOSS environment (Barthes 1989), a 
system of recursive frames capable of modelling objects with versions and well adapted to 
design activities, constructed on top of Common LISP. Some other agents are developed in C. 
Two databases MATISSE™ (an object-oriented database, commercial product of ADB) and 
EDBMS (an extended relational database developed at the Chinese Academy of Sciences) are 
used for storing design data and knowledge. 

3.2 Description of DIDE agents 

The current version of DIDE contains a number of agents, including Project manager, Monitor, 
Database of Engineering Standard, Object-Oriented Distributed Database, Graphical Tools and a 
group of Design Tools (as shown on Figure 2). 
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Figure 2 An experimental system architecture of DIDE. 

Project Manager: The interaction mechanism for agents in DIDE has been developed to meet the 
needs of human designers working on a collaborative project. Here the agent Project Manager is 
taken as this type of "human" agent for specifying the initial parameters, some constraints for 
the design project, supervising the design process and resolving some conflicts detected by 
Gear Box Assembly agent. In the future DIDE environment, there will be several agents for 
human specialists from different design groups or from different domains such as dynamics, 
electronics, economics, and process engineering, for discussion and negotiation. 

Monitor: This can be seen as an administrative agent. Generally, it works for the project 
manager. It receives all messages sent by all the other active agents in the same local system. All 
received messages are displayed on a text interface and a graphical interface is used to show the 
current system situation. When a new agent is connected to the system, an icon appears on the 
graphical interface, and when an old agent is removed from the system, the corresponding icon 
disappears. If there are some messages passing between agents, some signs appear on the 
graphical interface for a short time. At the same time, it modifies dynamically two HTML files: 
one for displaying the information about all active agents, another for showing the current 
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situation of the design project. The two HTML files are accessible by all participants of the 
project via Internet. Finely, it saves also all messages into a log file. 

Design Representation: This agent is responsible for the generation and management of 
geometric entities of a particular mechanical system. All classes, instances and methods are 
defined in this tool by using an object-oriented language, MOSS. The objects can be stored 
directly in a local extended relational database EDBMS or a distributed object-oriented database 
MATISSE™. 

Computational Tool: This agent is responsible for engineering calculations. It may be a Finite 
Element Analysis tool. Optimizer or some other engineering computation tools. Currently it is a 
simulated Optimizer for gear box optimization. 

Database of Engineering Standards: A database of national engineering standards is 
imperative in the domain of mechanical CAD. This agent is used for searching required standard 
dimensions in the database of engineering standards. 

Following four Design agents are developed specially for an experimental design example, the 
Gear Box Design. The agent Gear Box Assembly is used for global design, assembling the 
parts, propagating constraints and detecting conflicts and resolving some of them automatically. 
Three other agents are used to carry out sub-tasks (parts design) in parallel. For large design 
projects, the agent Gear Box Assembly corresponds the global system design, and the other 
agents should be developed to accomplish the design of the sub-systems, or sub-sub-systems. 

Gear Box Assembly: This agent is used to take the global design of the gear box. It 
decomposes the global design task into some sub-tasks and asks some special agents to 
accomplish the sub-tasks. Constraint propagation and verification is performed by this agent. 
Therefore, it is responsible for detecting conflicts by comparing the results obtained from the 
agents carrying out the sub-tasks. If some simple conflicts are detected, they may be resolved 
by some criteria in this agent. If not, a request message is sent to Project Manager to ask for a 
decision. At the end of a design or modification, the results can be shown on a 2D graphical 
interface, built on LispView. 

Bolt Assembly Design: It is used to take the sub-task sent by Gear Box Assembly for 
completing bolt assembly design: standardizing bolts, nuts, washers. It shares mechanical 
objects with other concerned agents through a local database EDBMS or through Distributed 
OODB MATISSE. 

Bearing Selection: It is used to take the sub-tasks sent by Gear Box Assembly for completing 
bearing selections. 

Gear Design: This agent is used to take the sub-task sent by Gear Box Assembly for 
completing the big gear design. It also shares objects with other concerned agents through 
databases (local or distributed). 

Graphical Tooll: Currently, AutoCAD™ on a SUN^^ workstation with SOLARIS™ 2.3 is 
used to display the design results. It can be also used to prepare a mechanical drawing or to let 
the drawings be modified by a human domain specialist. In this case, the agent is taken as a 
human agent and the main window of AutoCAD™ can be taken as a user interface for human 
specialists after some development on AutoLisp (This is not the case of current implementation, 
but is a future development). The data exchange with other agents is done by means of standard 
DXF (Drawing Interchange Format) and IGES files. 

Graphical Tool2: This graphical tool is SDRC™ I-DEAS^'^^ located on the network of 
DEC'’^^ workstations. In the current version of DIDE, this agent communicates with other 
agents by HTTP. This agent is used to test communications among agents located on different 
local networks and with different operating systems. The experimental goal is also to create 
graphical interfaces for production engineers to verify technological constraints. 

Local OODB: An agent has been developed to encapsulate the extended relational database 
EDBMS for storing the mechanical objects shared by concerned agents in the local network. 

Distributed OODB MATISSE: MATISSE™ is a commercial object-oriented database of 
ADB. An agent has been created by using the kernel system of MATISSE™ in the OS AC A 
project for storing MOSS objects created and used by all OSACA-based agents. In DIDE, we 
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use it as a second potential database for storing the mechanical objects shared by concerned 
agents. 

3.3 Inter-agent messages 

In the current DIDE implementation, only three types of messages (REQUEST, INFORM, 
NOTICE) are used for inter-agent communications. REQUEST messages can be sent by a 
method =request, and answers can be obtained by a method =get-result , e.g., 

(setq msgl-sent (-> *COM* '=request : receiver "agentS" 

: ontology "get-standard-bolt-diameter" 

: content (list GETSTB TABB.112 14))) 

INFORM messages can be sent in the same fashion by a method = reply or by a method 
=inf orm with an option : in-reply- to. And NOTICE messages can be sent in the same 
fashion by a method =inform but without the option : in-reply- to. Before being sent 
out, messages are filled with some default values like : sender , : id , or : language by 
the current agent. 

Here are some examples of the three types of messages (traces). 

agents : 

Msg-sent : AGENT3 REQUEST : id 829217636072571 :priority 1 : sender AGENT6 : receiver 
AGENT3 : language MOSS ; ontology 0 : commode 0 :reply-with OREQ15 : content (GETSTB 
TABB.112 14) 

Msg-received : INFORM : id 829217643641150 :priority 1 : sender AGENT3 : receiver 

AGENT6 : language MOSS lontology 0 :commode 0 :in-reply-to OREQ15 ;content (7 16 24 
10 ) 

Msg-received : NOTICE :id 829217840418471 .-priority 1 : sender AGENT4 : receiver 
AGENT6 : language 0 : ontology 0 : commode 0 : content (UNCONNECT AGENT4) 

agents : 

Msg-received : REQUEST : id 829217636072571 :priority 1 : sender AGENT6 : receiver 

AGENT3 : language MOSS ; ontology 0 -.commode 0 :reply-with OREQ15 : content (GETSTB 
TABB.112 14) 

Msg-sent : INFORM rid 829217643641150 rpriority 1 : sender AGENT3 : receiver AGENT6 
: language MOSS : ontology 0 : commode 0 : in-reply- to OREQ15 : content (7 16 24 10) 

Msg-received : NOTICE rid 829217840418471 rpriority 1 r sender AGENT4 : receiver 
AGENT3 r language 0 r ontology 0 r commode 0 r content (UNCONNECT AGENT4) 



3.4 Agent models 

As mentioned in Section 2, a model of agent including the symbolic models of other agents and 
the model of its own expertise is very important for cognitive agents. In the experimental DIDE 
environment, the "model of own expertise" for an agent is a simple knowledge base composed 
of the information about itself such as its name, address and competences or skills which may 
be some methods for activating some actions corresponding to the received requests. This 
simple knowledge base is stored as a MOSS object, instance of the class KNOWLEDGE: 

Entity-name KNOWLEDGE 

Terminal -property HAS -AGENT -NAME 

HAS -ADDRESS 
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HAS -ACTIVE? 

Structural -property HAS-SKILLS SKILL 

where the class SKILL: 

Entity-name SKILL 

Terminal -property HAS -SKILL -NAME 

HAS -KEY-WORDS 
HAS -EXPLANATIONS 

As a simple example of the above mentioned agent Computational Tool. 

HAS -AGENT -NAME agent? 

HAS-ADDRESS rouky.hds.utc.fr 

HAS -ACTIVE? yes 

HAS-SKILLS skill. 1 

where skill. 1 

HAS -SKILL -NAME OPTIMIZE 

HAS-KEY-WORDS gear-box-optimization 

HAS -EXPLANATIONS "optimize the main parameters of a gear box" 

The symbolic models of other agents are implemented by means of a knowledge base 
containing information about other agents obtained during interaction with the other agents. The 
information includes the agent's name, address, and its skills or competences. The same object 
structure is used to store this information about other agents. The knowledge helps the current 
agent to select one or more agents as sub-contractors for processing actions. The current 
message passing mechanism for obtaining this information is as follows: as soon as a new 
agent connects to the system, it broadcasts a message of REQUEST type and with context 
"REGISTER" to all other agents. Each one of the other agents receives this message, extracts 
the information of interest concerning the new agent such as its name, address and skills, and 
uses it to update its agent models, and then sends an "INFORM" message to the new agent. The 
new agent receives "INFORM" messages from all other agents, extracts important information 
and uses it to update its agent models. 

The task model is created and updated by each agent during its interaction with other agents. 
From receiving and sending messages, it extracts the important information's such as the 
project name, sub-task names, situation of the each sub-task and the time estimated for a sub- 
task or the time used for a completed sub-task. It saves also some important traces such as the 
content of the sending message and the results received from other agents for some REQUEST 
messages. In this fashion, when an agent sends a REQUEST message, it first verifies whether 
it sent a similar REQUEST previously and obtained a result. If so, it does not send the 
REQUEST message over again, but gets the results directly from its task model. 

3.5 A scenario - a small example 

As a design example, we considered a small mechanical system: a simple gear box, already 
described in details in (Shen and Barthes 1995a). Supposing that the necessary DIDE agents 
have all been connected to the system and each agent has established its agent models by 
message passing as mentioned in Section 3.4. 

In the current implementation, only three types of messages (REQUEST, INFORM and 
NOTICE) are used. This paragraph shows how an agent handles such messages (see Figure 3). 
When an agent receives a REQUEST message for some sub-task, this agent chooses a method 
according its internal KB (knowledge about itself), executes this method for completing the 
sub-task, and then sends the results by an INFORM message to the sender (agent) of the 
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REQUEST message. During the execution of the method, this agent may have to ask some 
other agents to complete part of the sub-task (sub-sub-task). It chooses an agent B according to 
its agent models (knowledge about other agents) and sends a REQUEST message to the agent 
B. After receiving the results by INFORM message sent by agent B, the agent resumes its 
work. During the work, some important information is saved in its local knowledge base for 
future use. A more complicated mechanism has been used to select an agent for carrying out a 
sub-task or sub-sub-task, which was described in details in (Shen and Barthes 1995b). A 
NOTICE message is similar to a REQUEST message, but when an agent sends a NOTICE 
message, it does not wait for a response; and when an agent receives a NOTICE message, it 
processes this message without sending any response. 




Figure 3 Treatment of message by an agent. 

At the beginning of the design or re-design process, the agent Project Manager sends a 
REQUEST message to the agent Design Representation to ask for defining all necessary objects 
including classes, instances and methods and storing them in the local database EDBMS or 
distributed database. If such objects exist in the local database or distributed database. Design 
Representation sends simply an INFORM message to Project Manager with ; content 
*OK*. If not. Design Representation defines all objects and stores them in the databases by 
sending NOTICE message to the agent Local DB, and then sends an INFORM message to 
Project Manager. Local DB is a reactive agent. It receives two types of messages: NOTICE 
messages for storing objects and REQUEST messages for loading objects. In the next 
paragraphs, we no longer discuss the messages between Local DB and the other agents. 

If the project manager desires to design or re-design a gear box, he can specify all the 
necessary parameters such as the transmission power, input rotational speed and reduction rate 
and some other constraints by means of a specific interface. The agent Project Manager sends a 
REQUEST message with initial data to Computational Tool according to its knowledge that 
Computational Tool can carry out this optimization and then waits for a response. If it does not 
receive a response for a period which can be known by the knowledge about the agent 
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Computational Tool and associated SKILLS, it repeats the REQUEST twice. And if there is still 
no response, the agent Project Manager considers that Computational Tool is not active and the 
design task cannot be done at this time. In the current implementation of DIDE, most of agents 
work on this type of mechanism. In the next paragraphs, we assume that all concerned agents 
are active and that each agent has decided which agent must be contacted and which SKILLS 
must be used according to its agent models. 

The agent Computational Tool receives the REQUEST message and does the calculation. 
Upon completion of the calculation. Computational Tool sends an INFORM message with the 
results to Project Manager. Here the results are some optimized gear box parameters such as 
gear module, the tooth number of the small gear, or the big gear width. 

After receiving this message, the agent Project Manager then sends a REQUEST message to 
Gear Box Assembly for designing or modifying the gear box. Gear Box Assembly decomposes 
this design task (which is itself a sub-task of the design project “Gear Box Design”) into some 
sub-tasks and sends multi-cast type REQUEST messages in parallel to three design or selection 
agents Bolt Assembly Design, Bearing Selection, and Gear Design. These three agents carry 
out the sub-tasks (selection or calculation) in parallel. During the selection or calculation 
process, each of these agents first loads the initial object data from local or distributed database, 
and then modifies them according the standardized or calculated results, and finally stores them 
into local database and distributed database if all these databases are active. In the current 
experimental example, each of these agents tries to obtain data from the local database first if 
they exist, loads them; but if not, it tries to obtain them from the distributed database. The 
results are stored into two databases whenever they are active. After completing the sub-tasks, 
each of these three agents sends an INFORM message to Gear Box Assembly. The : content 
of the INFORM message is *OK* if the sub-task is successfully finished. During the selection 
and design process in the Bearing Selection and Bolt Assembly Design, the agents need 
standard tables to obtain standard (nominal) diameter and other standard dimensions of the 
bearings, the bolts, the nuts or the washers. They send a REQUEST message with a calculated 
diameter to Database of Engineering Standards and wait for a reply. The agent Database of 
Engineering Standards receives this type of messages and searches for the requested 
information in the database of national engineering standards and then sends an INFORM 
message with the results to requesting agents. 

The agent Gear Box Assembly receives the messages from three other design agents, analyses 
the results and verifies the global constraints. If there are some conflicts. Gear Box Assembly 
tries to resolve them according to its knowledge. If it cannot resolve some conflicts, it sends a 
REQUEST message to Project Manager to ask for a decision. After a decision is made, it re- 
sends a multi-cast type REQUEST message to the design and selection agents. If there is no 
conflict among the received results. Gear Box Assembly resumes its work and revises some 
parameters of the top-case and low-case, such as the diameters of the bolt holes. The object data 
have to be loaded from the local or distributed database before the verification, and stored into 
these databases after that verification and modification. And finally. Gear Box Assembly sends 
an INFORM message to Project Manager with : content *OK*. 

After sending a REQUEST message or receiving an INFORM message, each of above 
mentioned agents stores some important information such as the contents (keyword with initial 
parameters in the REQUEST message and results in the INFORM message) of the messages in 
its task model as mentioned in Section 3.4. Afterward, when an agent will send a REQUEST 
message, firstly it verifies whether it sent a same REQUEST before and had obtained a result. If 
yes, it does not re-send this REQUEST message, and gets the results directly from its task 
model. 

The Project Manager receives the INFORM message from Gear Box Assembly, may view the 
design results on a 2D graphical interface developed on LispView, may send a message to 
Graphical Tooll for displaying the results which can be obtained from the databases, and may 
also send an E-mail with a http pointer of the IGES file to the production engineer for showing 
the results on I-DEAS {Graphical Tool2), which will be used for production engineers in future 
computation. 
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The Monitor receives all above messages sent by all other active agents in the same system, 
displays all received messages on a text interface, shows the current system situation on a 
graphical interface, and modifies dynamically two HTML files about the agent information and 
the current situation as mentioned in Section 3.2. 

Figure 4. Shows examples of possible message paths among the main autonomous agents of 
DIDE in the local network. 
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Figure 4 Possible message paths among the main DIDE agents. 



4 CONCLUSION AND DISCUSSION 

The objective of our research is to develop a distributed intelligent design environment for 
supporting cooperation among the existing engineering tools and human specialists. The 
teclmiques of Distributed Artificial Intelligence provide a natural model for such applications. In 
this paper, we discussed a distributed architecture for an intelligent design environment based 
upon asynchronous cognitive agents combining a number of mechanisms already found in the 
literature. Such an architecture is specially useful for large design problems. 

We have implemented an experimental design environment using a platform, OSACA, to 
support the cooperation among the engineering tools organized as independent agents. In this 
environment, we have successfolly implemented communications among about ten independent 
agents located in the different workstations, which proves that the architecture proposed in this 
paper is feasible. However, as a result of our experiments in the first version of our 
implementation, we found that some commercially available products, although usable, are not 
the best support for this kind of approach. Our goal, as mentioned previously, is to obtain first 
hand experience in the case of large design projects. 

According to our experience, it can be found that multi-agent systems for engineering design 
problems have some interesting advantages: (i) a multi-agent system can be developed into a 
real open system, which makes the design system dynamic, i.e., agents can be added and 
removed as needed without disturbing the working system; (ii) each agent is autonomous and 
independent, which makes the multi-agent design system less complex than the blackboard 
system, and also makes it easy to integrate the existing engineering tools into the design system 
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so as to resolve the legacy problems; (iii) it is easy to integrate human elements, i.e., it is easy 
to develop “human agents”-user interface for human specidists; (iv) it makes the design system 
efficient through pardlel executions; (v) it is flexible, which means that it is easy to transfer one 
application to another application by implanting some new agents. However, there are also 
some drawbacks: (i) it is not easy to build and test multi-agent systems; (ii) it takes much time to 
establish agent models and local knowledge models (task models), and the inter-agent 
communication also takes much time, and therefore it is not efficient for small design projects; 
(iii) there are also some other problems difficult to be solved, such as shared ontologies, or re- 
establishing temporary consistency in the global system. 

The experimental research of the project DIDE produced some useful insights that are 
applicable in future developments and in other research projects. Here is a brief discussion of 
some interesting issues based on our experience. 

4.1 Cognitive agent 

An important objective of our research is to design cognitive agents for the DIDE project. A 
cognitive agent is an agent which has at least the following properties: (i) it is knowledge- 
based; (ii) it has knowledge about other agents and the knowledge is obtained during the 
interaction or communication with other agents or learned from a special "tutor" agent; (iii) it is 
not simply a reactive one, i.e., it does not only reply to the requests from other agents, but it 
can also give some suggestions or propositions to the current solution according to its 
knowledge about the current design task. According to our experience, it is feasible to build 
agents able to memorize previous actions or capable to recognize the task and sub-tasks being 
tackled. Using artificial intelligence techniques, such agents can be developed to react to certain 
contexts and criticize or provide some advice to other agents. 

4.2 Agent life cycle 

One of the major problems for developing truly open systems is that of being able to insert or to 
remove agents on a given application without halting or reinitializing the (distributed) system. 
Indeed, since large design projects last several months or even several years, new tools or new 
services appear during the life of the project; similarly, existing tools get upgraded. Thus, it is 
necessary to accommodate such changes smoothly without disturbing the project. Traditional 
approaches, in which a group of powerful tools may be integrated into a large, efficient, 
decision support system, do not allow it. Such approaches are viable only if the problem 
domain is static, i.e., the tools, design rules, and production process do not change over the 
product life-cycle. Indeed, when new services are appended to a group of cooperating 
processes it is usually necessary to recompile all programs on all machines on the network. This 
is clearly unacceptable. 

In the OSACA-based DIDE system agents may appear or disappear with minimal disturbance 
to the whole system. New agents, whether slaves (e.g., some encapsulated existing tools) or 
more active, are created from generic agents. They possess communication capabilities and 
some expertise (which may result from programs, rules, databases, etc.). They are not required 
to know anything about the existing agents, nor of the ongoing tasks to be solved. 

When a new agent connects to the group, it immediately can receive broadcasted messages 
and respond to them. Other agents are not modified by the introduction of a new agent, i.e., the 
system keeps running. Once a new agent is connected, it must build its own representation of 
the task being solved as well as acquire information about the other agents. Currently, two 
strategies can be used: (i) either a "tutor" agent helps the new agent to do it - this amounted to 
downloading the information in the MARS project (Abriat 1991); or (ii) models will be build as 
needed through exchanged messages. Two things could be done in addition: (i) an agent could 
advertise its skills as soon as it is connected; (ii) an agent could inquire actively once it is 
connected by broadcasting requests. Such behaviours which can be installed in the generic 
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agent from which more specific agents are derived, are not currently implemented in the 
OSACA agents. 

An active agent may die (temporarily or definitively) or be removed from the system. In such 
a case, generally nothing special is done. In the current DIDE experimental environment, if an 
agent is normally disconnected, all other agents will note it and modify their agent models 
accordingly. 

4.3 Agents and Web tools 

The World Wide Web was originally developed as an infrastructure for research collaboration. 
HTML provides a standard file format for exchanging information among remote agents. 
Hypertext in HTML can be implemented as special “anchors” that point to resource links to 
other concerned files from HTTP servers throughout Internet. WWW also includes links to 
FTP and remote procedure scripts, which can be used to transfer some large files such as DXF 
or IGES files, and even image or audio- video files in large design projects. 

In the DIDE experimental environment, a Web browser, Netscape (or HotJava), has been 
used to display the information about the active agents and the current situation of the working 
environment. This is very interesting for cooperation among the design teams located on 
different sites and communicating via Internet. HTTP has been selected as a main remote 
communication protocol for DIDE project. According to the experiments in our research group, 
it is possible to develop agents using Java or Python, so as to use a Web browser like HotJava 
or Netscape as a user interface for human specialists. 

4.4 Openness and dynamics 

For large engineering design projects, the design process often lasts for a long time, thus, the 
openness of a system is very important and truly central to the approach. Indeed, it is not easy 
to let agents join and leave the working system dynamically. Our goal is to verify whether it is 
actually possible to build truly open systems, that is, systems for which users can freely add or 
remove agents without having to halt or to reinitialize the work in progress in any way. The 
OSACA-based DIDE environment implements this idea. 

Here we give an example of a situation that we encountered during experimental stages, 
showing the openness and the dynamics of our system. During the bolt assembly design 
process. Bolt Assembly Design sends a REQUEST message to Database of Engineering 
Standards for obtaining standard bolt length and bolt thread length. Database of Engineering 
Standards received the messages and called the corresponding functions (skills) to search 
standard data. But there was a problem in the function GETSTTL (for searching standard bolt 
thread length) and this agent was out of order and became non-active. We had to "repair" this 
agent by redefining this function and then re-start the agent. Afterward, the agent continued to 
receive REQUEST messages, dealt with the received messages and sent out the results without 
disturbing the whole working environment. Bolt Assembly Design waited for results from 
Database of Engineering Standards for several minutes without response and subsequently 
repeated the REQUEST message twice. This mechanism allowed Database of Engineering 
Standards to receive the REQUEST message from Bolt Assembly Design and to complete the 
design process. 

4.5 Communication 

Communication is the key issue in distributed systems. Indeed, the complexity of building a 
single system has been traded for a reduced complexity of each agent. However, the difficulty 
has been transferred in part to the level of communications and to the issue of combining the 
separately achieved sub-tasks. 

Communication can be implemented in very different ways, depending on the nature of the 
agents, the global architecture of the system, the timing of the exchanges, or the number of 
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receivers for a message. Indeed, communications can occur between humans and/or machines; 
they can be direct by means of messages or indirect by posting; they can be synchronous or 
asynchronous; they can concern a single agent or several agents. 

Communication can be direct or indirect. In multi-agent systems communication is directly 
done between agents by using explicit messages. In multi-expert systems, communication is 
done indirectly by writing to the blackboard (which, however, is equivalent to a multicast 
communication strategy in the case of partitioned blackboards; broadcast otherwise). In the 
latter case, the communication mechanisms can be quite simple, like the SHARED workspace 
(Wong and Sriram 1993) in the DICE projects. 

Communication can be synchronous or asynchronous. Even if synchronous communications 
(blackboard style) are very useful for systems in which the cooperating agents have to work 
simultaneously, such as a multimedia teleconferencing system (Lee, Mansfield, and Sheth 
1993), we found that they are not necessary for the type of the design work we are considering 
because we would like to develop environments for large design problems, for which the 
design period is often very long and synchronous communications in this case are neither 
required, nor efficient or economical. 

4.6 Shared ontologies 

An active agent system works by exchanging messages at a high semantic level. This raises the 
question of shared vocabulary and common ontologies, and also of the initial expert knowledge 
content of each agent prior to its connection to the network. A review of such questions can be 
found in (Cavalli et al 1991) in the context of "Enterprise Integration" and in (Gruber 1993) in 
the context of "Ontologies and knowledge sharing." Our approach in this domain is to manually 
organize needed concepts into minimal ontologies as needed. Then, whenever a new agent 
enters the system, it is its responsibility to make sure that the system contains all the needed 
ontologies. If not, it must bring the missing ontologies. 

4.7 Conflict resolution 

Conflicts occur in multidisciplinary design environments mainly for two reasons: individual 
participants in the cooperative process lack the complete knowledge of global objectives 
necessary to ensure that their locally-preferred solutions are in alignment with these higher 
objectives, and individual disciplines have individual ideas about what constitutes the best 
design. Even individual design requires trade-offs because of competing design criteria, such as 
safety, cost and social acceptance, as well as artefact requirements and specifications. The 
ability of designers to avoid or minimize conflicts through judicious trade-offs and other 
methods is one of their most valuable skills. 

Resolution and detection of conflicts are especially difficult when the design task as well as 
knowledge concerning such competing factors is distributed among different actors with 
different perspectives. Certain methods such as negotiation, hierarchical structures, constraint 
weakening, creation of new variables and user interaction can be used for conflict resolution. It 
is also possible to combine several methods in the same system. 

Researchers have developed conflict resolution strategies for various types of conflicts: 
introducing an approach to conflict resolution based on classifying the conflict and mapping it to 
a specific strategy (Klein 1991); resolving conflicts in resources allocation among cooperative 
agents (Conry, Meyer, and Lesser 1995); resolving conflicts via negotiation (Sycara 1990; 
Chu-Carroll and Carberry 1995; Dunskus et al 1995; Bahler, Dupont, and Bowen 1994); 
assisting the designer by using expert systems that offer criticisms and suggestions concerning 
design decisions in SNEAKERS (Douglas, Brown, and Znger 1993). Two interesting 
examples can be found in the project NEXT-LINK (Petrie et al 1994) and in the project 
SHARED-DRIMS (Pena, Sriram, and Logcher 1993). NEXT-LINK uses a simple and 
ubiquitous notion of constraint to represent all conflicts and provides a support for human- 
guided conflict resolution. On the contrary, SHARED-DRIM uses an automatic conflict 
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resolution technology for resolving the known conflicts when solutions are available in its 
knowledge base. 

In DIDE, we leave each group of designers develop possible conflicting partial solutions 
(divergence) (Barthes 1993). Such solutions are managed as parallel versions. Then, at the 
review meetings all groups have to compromise on a commonly agreed solution or on a solution 
imposed by the project manager (reconciliation). This relates to the global consistency of the 
project and not to the consistency within each partial solution, which we have not yet addressed 
(see also Project Manager in the Section 4.2.2). 

DIDE is an ongoing research project. Some important issues are being studied and developed: 
remote communication, conflict detection and resolution, and shared ontologies. 
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Abstract 

This paper proposes the system named as TICCSS’ (Problem Interactive Clarification 
and Concurrent Solving System). PICCSS is developed for application of the Concurrent 
Problem Solving (CPS) framework. The CPS framework provides a new problem solving 
paradigm. The main features of CPS are 1) connection-oriented knowledge representation, 
2) top-down function refinement, and 3) integration of spatial and temporal structures. 
PICCSS can support a designer on conceptual design problems where a product and 
manufacturing processes should be considered. After illustrating PICCSS architecture, 
the sequence of using PICCSS to design a product and make its manufacturing plan is 
described using an example of designing a certain mechanical pump. This experimental 
ccLse study shows that PICCSS can deal with the conceptual design and provide not only 
a rough product draft but also a rough manufacturing plan very efficiently. This paper 
demonstrates these results with the reusable knowledge for mechanical design. Finally, 
our system is evaluated from some viewpoints and future enhancements to be made are 
given. 

Keywords 

conceptual design, feature based modelling, knowledge representation, ill-defined problem, 
CAD, CAPP, concurrent engineering 



1 INTRODUCTION 

Product development in manufacturers can be regarded as a problem solving process, 
in which both design knowledge and manufacturing knowledge are used to satisfy the 
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various requirements in the particular manufacturing circumstances. Although this kind 
of problem is asked to be supported by computers, designers and planners usually carry 
out most of their tasks without computers. One reason is that the product development is 
an ill-defined problem, and there are few problem solving frameworks for such ill-defined 
problems, particularly using an appropriate knowledge representation schemes (Ohsuga 
1993) (Kimura 1993). 

The purpose of this paper is to demonstrate applicability of our problem solving frame- 
work named CPS (Concurrent Problem Solving) to conceptual design problems in the 
early stage of the product development. Generally in conceptual design, the problem itself 
has not yet clarified until the solution of the problem is obtained. Furthermore, designers 
should consider the problem using their knowledge about both the product and the man- 
ufacturing processes. In order to early detect inconsistency in the problem, these different 
types of knowledge have to be treated concurrently. Therefore, the required framework 
should have capability to deal with ill-defined problems and to present a common platform 
for knowledge about products and manufacturing processes to be employed. 

In manufacturers, the term ‘product design’ and ‘manufacturing process planning’ have 
many implications. This paper emphasizes that product design determines a spatial struc- 
ture of the problem elements, while manufacturing process planning determines a tem- 
poral structure of the problem elements. Conventional product design and conventional 
manufacturing process planning are dealt with sequentially. However, supposing spatial 
and temporal aspects of the problem, these two types of problems cannot completely be 
separated in the conceptual design. Thus, the aim of our research is to integrate a problem 
designing a spatial structure and a problem designing a temporal structure, that is, to 
integrate a product design and manufacturing planning. 

The rest of this paper is organized as follows: the next section introduces the new 
problem solving framework underlying our system, and Section 3 shows the overview of 
the proposed system PICCSS (Problem Interactive Clarification and Concurrent Solving 
System). Section 4 addresses the practical knowledge necessary for the mechanical design 
in our representation scheme, and then, an experimental case study of a product develop- 
ment is demonstrated in Section 5. Section 6 discusses the result of the experiment, and 
finally in Section 7, concluding remarks are given. 



2 CONCURRENT PROBLEM SOLVING FRAMEWORK 

Problem solving is one of the most basic activities of human beings. There are many 
problem solving frameworks proposed in the past researches. Most of the problem solving 
frameworks effective for the industrial applications are domain dependent, whereas a few 
frameworks such as GPS (Newell and Simon 1963) and STRIPS (Fikes and Nilsson, 1971) 
are domain independent. Our problem solving framework used in this paper is classified 
into the latter, that is, the framework is independent of the domain knowledge. 

In this paper, problem solving is defined as a process which is ‘filling up gaps detected 
between requirements and facts.’ When both requirements and facts are represented by 
structures of elements, the gaps correspond to topological and parametric differences 
between the two structures. To fill the gaps, the problem solver ha^ to modify and maintain 
the structures. The main features of CPS are the following three (Nishioka, 1996a): 
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• Connection- oriented knowledge representation — Knowledge is characterized depend- 
ing on how the elements of knowledge are connected with each other. The elements 
themselves are less important than the connections of them. In the representation 
scheme, elements called primitives have a parameter and constraint /causality proto- 
types which will compose a computational model. 

• Top-down function refinement — Problem solving begins with rough and partial knowl- 
edge, and then proceeds with more detailed knowledge which is obtained through the 
problem solving. Functions, which associate requirements with facts, are refined in a 
top-down manner, so that granularity of the represented knowledge can vary according 
to this top-down process. 

• Integration of spatial and temporal structures — The problem is treated as both spatial 
structures and temporal structures. These two types of structures are defined using 
the common representation scheme, where spatial elements and temporal elements are 
closely connected in a primitive level. These integrated structures can be visualized 
from one of some spatial aspects and a temporal aspect. 

2.1 Knowledge Representation 

Knowledge representation on the CPS framework consists of two specification forms: prim- 
itive and template. Primitives are building blocks of knowledge, so that they compose a 
problem by connected with each other. These primitives are independent of particular 
situations, and they are not affected by experineces. Thus, primitives can be defined in 
advance without information about particular problems. 

On the other hand, templates are pieces of knowledge, which represent various empirical 
situations. Knowledge called know-how and knowledge about spatial patterns such as 
products and parts can be represented by templates. Many conventional representation 
schemata such as frame (Minsky 1981) and script (Schank 1982) are similar to templates 
in their representation target. However, their specification looks different. A template 
consists of primitives in a graph structure, where nodes correspond to primitives and arcs 
correspond to their connections. 

Primitives can be divided into four classes: entity^ process, relation, and operator. En- 
tities and relations represent a spatial structure of the problem, whereas processes and 
operators represent a temporal structure. On the other point of view, entities and processes 
are conceptual elements, whereas relations and operators are computational elements. The 
designer directly perceives some substances as conceptual elements, while computational 
elements are calculated by the computer. Primitives of each class are characterized as 
follows: 

Entities are primitives representing physical substances. All objects visually perceived 
by designers can be classified into entities. In other words, objects represented by 
entities spread over the spatial world. Connected with relations which have position 
parameters, entities can be drawn on a 2-D drafting area. 

Processes are temporal primitives representing activities, methods or procedures. They 
represent temporal substances which can be associated with various events and their 
pre/post-conditions. Processes can be drawn on a temporal chart if they have connec- 
tion with some operators. This chart shows a process plan of the problem. 

Relations are primitives which represent static relationships between more than two 
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primitives. Some relations connected with one primitive represent its attributes. Each 
relation has a parameter and some constraints. Some relations in the problem structure 
will be invalid depending on the parameter. 

Operators are primitives representing events with their causal relationships. These causal 
relationships are used to make state transitions. Each operator can modify a relation 
parameter of its post-condition, if all of the preconditions are valid. In our scheme, a 
‘time’ is defined by state transition, thus each operator will correspond to a ‘time.’ 

Most of the conventional knowledge representations such as object-oriented approach 
relatively focus on conceptual elements. In other words, represented elements have many 
information about the target substances independently. In contrast to these approach, 
our representation scheme is connection-oriented. All the data, which the computer needs 
to calculate the problem, are included in the computational elements, i.e., relations and 
operators. Conceptual elements such as entities and processes are defined by connecting 
these computational elements in order to represent themselves. 

In our research, the data structures have been prescribed for entities, processes, relations 
and operators. First, each primitive has a class name, a super class name and indexes. 
Second, each of entities and processes has properties which suggest sufficient connections 
for the class. Furthermore, each relation has a parameter and constraints, while each 
operator has a temporal parameter (time) and precedence and causality. More details of 
the representation scheme are discussed in somewhere else(Nishioka 1996b). 

2.2 Main Flow of CPS 

To deal with an ill-defined problem, the main flow of CPS performs in a top-down re- 
finement loop, where the problem is gradually refined with additional requirements and 
facts. During the refinement loop, the human or the knowledge-base gives some functions 
which associate the requirements with the facts. When the problem structure has no gap 
between the requirements and the facts, this top-down refinement loop is terminated. 
There are three main steps in CPS as follows: 

Problem Clarification: To begin with, requirements of the designer and facts of the 
circumstance are clarified in the computer according to the knowledge representation 
scheme. This step articulates the problem itself, so as to represent the problem in the 
computer in the form of a structure of primitives. Functional sentences are used for 
articulating the problem and transforming it into the computer. 

Consistency Management: The clarified structure may initially have some inconsis- 
tencies in terms of constraints and causality. The consistency management deals with 
this inconsistencies. The constraint satisfaction is performed to establish a spatial struc- 
ture, while the state transition is executed to establish a temporal structure. Precedence 
is created dynamically on operators through the state transition. This two calculation 
modules are executed complementarily. 

Problem Evaluation: In this step, the results of the consistency management are eval- 
uated and visualized for the designer. Even if the problem represented in the computer 
has no gap between the requirements and the facts, it may not commit to the real 
world problem. Therefore, the problem is visualized using some significant viewpoints. 
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so that the designer evaluates these solution candidates with his/her own knowledge. 
The main loop is terminated depending on the evaluation. 



3 PICCSS IMPLEMENTATION 

PICCSS is a prototype system where the CPS framework is underlying. It is implemented 
by C++ and Motif on an UNIX workstation. This prototype system works for the user’s 
problem which is not clear in the beginning and has spatial and temporal aspects. PICCSS 
supports the user to solve the problem interactively, by clarifying the problem itself and 
making a consistent structure in which the requirements and the facts are definitely as- 
sociated. 

PICCSS prescribes a guideline of problem solving and a knowledge representation 
scheme. The CPS framework doesn’t have any knowledge about particular problem solv- 
ing. Thus, in PICCSS, all kinds of knowledge are detachable in the knowledge-base, the 
database and the case-bcise. Generally, problem solving performs well entirely depending 
on the stored knowledge, so that the knowledge in PICCSS takes the most important role. 
The three storage areas for knowledge are characterized as follows: 

Knowledge-base: Knowledge represented by primitives or templates is stored in the 
knowledge-base. Primitives are prepared in advance by knowledge engineers to suffi- 
ciently represent various problems in the domain. Templates are extracted from the past 
cases considering efficiency of reuse of the knowledge. Both primitives and template 
are retrieved using indexes. 

Database: In the real world, facts of the circumstance consist of various numerical data. 
These data are prepared in the database and will be substituted for the parameters of 
the primitives. The database manages the data associated with the fact of the problem 
by monitoring circumstances or allowing the user to input significant data. 
Case-base: The case-base has various instances of the problem solving in the past. These 
instances contain not only final solutions of the past problems but also an incomplete 
part of the problem structure through the problem solving processes. These instances 
are called cases. The stored cases are used to extract new templates or retrieved directly 
for similar problems. 

PICCSS has several modules as shown in Fig. 1. All of the modules are associated with 
the problem structure, which the system is clarifying through the problem solving. Each 
module has a graphical user interface to execute its functions cooperatively with the user. 
Functions of each module are briefly described as follows: 

Requirement Editor supports articulating the users’ requirements using functional sen- 
tences, and then the terms obtained here are translated into primitives. These primi- 
tives are connected considering the semantics of the sentence. 

Structure Editor displays the problem structure and allows the user directly to make 
or modify the connections of the primitives. According to the level of the problem 
refinement, this editor controls the granularity of the displayed primitives. 
Parameter Editor substitutes values of requirements or facts for parameters in the 




44 



Part One Architecture for Knowledge Intensive CAD 




■\ 



Template^ 

-► ^Prim itive 

Knowledge- 
base 



Database 

n 




Problem 
Visual! zer 



( P: 

I S 



\ i ^ 



Problem / 
I Structure 



Pareuneter 
Editor 



Structure 

Editor 



Constraint 

Manager 



CAD/ CAM 
CAPP etc. 






Other 

Systems 



implemented 
not implemented 



Figure 1 System Architecture 

problem structure. This editor also changes attributes ‘fixed/free’ and ‘valid/invalid’ 
of each parameter. 

Constraint Manager calculates parameters to satisfy the constraints and causality of 
the problem. The constraint satisfaction module performs to calculate a spatial struc- 
ture, whereas the state transition module provides a temporal structure. 

Problem Visualizer visualizes the problem from some significant viewpoints. In visual- 
izing, some primitives of the problem are filtered, and then the remainder is transformed 
on a selected coordinate system. 

Knowledge-base Manager retrieves primitives or templates using indexes. If an ap- 
propriate knowledge is retrieved, it is applied to the corresponding part of the problem 
structure. Similarity between a template and its target is considered there. 

Fact Emulator monitors the circumstances and prepares data of the facts necessary for 
constructing or solving the problem. Fact data stored in the database are substituted 
for the corresponding part of the structure. 

Case Manager registers the new case of the problem solving, and retrieves an appro- 
priate knowledge from various problem structures in the past. This manages the cases 
in order to efficiently reuse the stored knowledge. 

The problem structure obtained as a result can be translated into some data formats 
and output to the other systems such a.s CAD/CAM and CAPP. For example, CAD 
system needs spatial aspects of the problem, thus 2-D or 3-D shapes of the product are 
composed from two or three views of the single dimensional drafts respectively. On the 
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other hand, temporal cispects of the problem are used for CAM or CAPP systems, which 
deal with sequences of operations, manufacturing processes and so on. 

According to the CPS framework, PICCSS performs with the user to solve his/her prob- 
lem. First of all, the problem clarification step is executed on Requirement Editor and 
Fact Emulator, both of which are associated with Knowledge-base Manager. Secondly, 
Constraint Manager performs by means of constraint satisfaction and state transition. 
Finally, in the problem evaluation step. Problem Visualizer shows the structure in signifi- 
cant ways to evaluate the problem. Structure Editor and Parameter Editor are frequently 
employed through the problem solving process. 



4 KNOWLEDGE FOR MECHANICAL DESIGN 

In the CPS framework, primitives are ontology of the problem domain. Here, ontology is 
a system of vocabulary used as a fundamental concepts in building an artificial system 
(Mizoguchi 1995). Thus, it is necessary to prepare the primitives sufficient for the problem 
domain in advance. Once primitives are registered, they determine the problem domain 
where the designer can deal with the problem. This section shows some usable primitives 
for the mechanical design field. PICCSS currently ha,s more than 850 primitives for the 
mechanical design. 

4.1 Primitives for Products 

The registered primitives in PICCSS include entities which compose a spatial structure of 
a problem. In the mechanical design, a spatial structure contains a shape of a product, a 
shape of a part, an assembly relation of parts, and so on. In order to efficiently represent 
the spatial structure, primitives listed in Table 1 are prepared. Table 1 shows some typical 
entities, where various relations and operators are listed as their properties. These entities 
almost correspond to form features of the feature-based design paradigm (Salomons 1993). 

The representation of the entities takes a single-dimensional coordinate system, so that 
geometric features consist of three types of entities: x-coordinate entities, y-coordinate 
entities and z-coordinate entities. Moreover, each coordinate entity may be divided into 
two directions such as right direction and left direction, when the feature is not symmet- 
rical. For example, the entity step_circ, which represents a circular step on a cylinder, has 
six sub-classes: step_circ_r, step.circJ, step_circ_u, step_circ_d, step_circjf, step_circ_b. 

Each entity connects with relations or operators. These connections sufficient for rep- 
resenting the target element are specified in the property list of the entity. For exam- 
ple, cylinderJi has 15 properties: org_x, org.y, org.centerJi, org_center_v, diamJi, mir- 
ror _face_v, length Ji, center Ji, center_v, cface.u, cface.d, pfacej*, pfaceJ, cylinder.exist, 
and making.cy Under. In this property list, making_cylinder is an operator, and the others 
are relations. 

Some of relations connecting the entities have constraints. These constraints affect to 
characterize each entity. For example, lengthJi of cylinderJi has a constraint which defines 
the length of the cylinder. The expression shows that the distance between pface_r and 
pfaceJ is equal to the parameter of length Ji, i.e., pfacej — p faced = length Ji. In some 
cases that relations connect two different entities, the constraints might describe binary 
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Table 1 Entities for Product Model 



entity name 


super class 


list of properties 


block.v 


block 


orgjc org_y org.center Ji org_center_v mirrorTaceJi 
mirror_face_v lengthJi length.v center.v center Ji pface j 
pfaceJ pface.u pface.d block_exist making_block* 


cylinder Ji 


cylinder 


orgjc org_y org_centerJi org_center_v diamJi mirrorTace.v 
lengthJi centerji center.v cface.u cface.d pfacej* pfaceJ 
cylinder.exist making_cylinder* 


tubeJi 


tube 


orgjc org_y org_center Ji diamJi length Ji diamJnJi 
thick.circ.u thick_circ_d centerJi cface.u cface.d pfacej* 
pfaceJ cface.ccv.u cface.ccv.d tube.exist making_tube* 


step.circj* 


step.circ 


orgjc org.y org.pfacej* diam.ppdji diamJi depth.circ.d 
depth.circ.u centerji cedge.d cedge.u cface.d cface.u pfacej: 
has.step.circ cutting.step.circ* 


slot.circJi 


step.circ 


orgjc org_y diam.ppdji diamJi gapJaceJi depth.circ.u 
depth.circ.d centerji cedge.d cedge.u cface.d cface.u pfaceJ 
pfacej has.slot_circ cuttingjslot.circ* 


holeJhroughJi 


hole.through 


orgjc org_y diamJnJi length Ji center Ji pface j pfaceJ 
cface.ccv.u cface.ccv.d hasJiole.through cuttingjiole.through* 


hole.blind.d 


hole.blind 


orgjc org.y diamJn.v depth.cedge.d center.v cedge.d pface.d 
cface.ccvj: cface.ccv J hasjiole.blind cuttingjiole.blind* 


pocket.d 


pocket 


org_x org.y org_center.v mirror Jace.v gap JaceJi depth.d 
center.v edge.d pface.d pfaceJ pfacej has .pocket 
cutting.pocket* 


thread.cvxj- 


thread_cvx 


orgjc org.y diamJi thread Jengthj: centerJi cface.d cface.u 
pfacej* cedge j has.thread.cvx cutting.thread.cvx* 


thread_ccv_r 


thread_ccv 


orgjc org.y diamJnJi threadJengthj centerji cface.ccv.d 
cface.ccv.u pfacej has.thread.ccv cedgej: cutting_thread_ccv* 



The properties with * mark are operators, the others are relations. 



relationships such as mating relations, assembly relations and some other manufacturing 
relations. 



4.2 Primitives for Manufacturing 

Most of the other registered primitives in PICCSS are relative to the temporal structure 
of a problem. Here, temporal structures correspond to manufacturing processes which 
have various causality. Although entities corresponding to machines, tools, materials and 
other resources are important in detail, manufacturing processes are mainly represented 
by processes. 

Processes for manufacturing are briefly listed in Table 2. The name of super class and 
the list of properties for each process can be shown there. For example, cutjstep_circ 
is a sub-class of cutjstep and has six properties: cuttingjstep.circ, cuttingjstep_circ_dur, 
chucking, chucking.dur, tooLprepared and has_step_circ. In this list, cuttingjstep.circ and 
chucking are operators which will compose a temporal structure. The others in the list 
are relations, which represent preconditions, post-conditions or constraints associated with 
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Table 2 Processes for Manufacturing 



process name 


super class 


list of properties 


cut_step_circ 


cut.step 


cuttingjstep.circ* cuttingjstep.circ.dur chucking* 
chucking.dur tooLprepared has.step_circ 


cut.off.bar 


cut.olf 


cutting_ofLbar* cutting_off.bar.dur chucking* chucking_dur 
tooLprepared cylinder.exist 


cut_off_block 


cut.off 


cutting.off_block* cutting_off_block_dur chucking* 
chucking.dur tooLprepared block_exist 


cutJioleJhrough 


cutJiole 


cuttingJiole.through* cuttingJiole_through_dur chucking* 
chucking.dur marking_center* marking_center_dur 
tooLprepared has Jiole.through 


cutJiole.blind 


cutJiole 


cuttingJiole.blind* cuttingJiole.blind.dur chucking* 
chucking.dur marking.center* marking_center_dur 
tooLprepared has Jiole.blind 


cut .pocket 


cut 


cutting_pocket* cutting_pocket_dur has.pocket 


cut .thread 


cut 


cutting_thread_cvx* cutting_thread_cvx_dur chucking* 
chucking.dur tooLprepared has.thread.cvx 


tap 


cut 


cutting_thread_ccv* cutting_thread_ccv_dur chucking* 
chucking.dur tooLprepared has.thread.ccv 


insert 


insert 


labor.exist inserting* inserting_dur inserted 


fix.by.thread 


fix 


fixing.by .thread* fixing_by_thread_dur labor.exist 
fixed.by.thread 


press j*ound 


press 


pressingjound* pressingjround.dur holding* holding.dur 
tooLprepared platejound.exist 


takeJrom.stock 


take 


existJn.stock takingJromjstock* transfering* 
transfering.dur exist 



The properties with * mark are operators, the others are relations. 



the operators. In the case of cutjstep.circ, cutting»step_circ_dur has a parameter of the 
precedence of cutting_step_circ. The relation chucking_dur hcis a constraint and a param- 
eter which define the duration between two operators: chucking and cuttingjstep_circ. 
Finally, tooLprepared is the precondition and hasjstep^circ is the post- condition of cut- 
tingjstep.circ. 

It is important to consider whether a constraint or precedence the designer chooses 
to represent cis a relationship between two operators. A permanent relationship between 
two operators might be generally represented by a constraint of a relation. On the other 
hand, where the target operator (successor) of the relationship is determined dynamically, 
it should be represented by precedence of the target operator (predecessor) with other 
relations such as a duration parameter. 

4.3 Product and Process Correspondence 

In the mechanical design, correspondence of the product shape to the manufacturing 
processes in the aggregate level is very difficult to find out because of its combinatorial 
complexity. However, in the primitive level, each feature of the product shape can be 
associated with some certain manufacturing processes. Consequently, it is possible to 
prepare various typical correspondence between a product and processes in advance. 
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Figure 2 Example of product and process correspondence 



For example, Fig. 2 shows a template which represents correspondence between enti- 
ties of a product and processes of manufacturing, where nodes with a ellipse correspond 
to entities, nodes with a rectangle correspond to processes, nodes with a small square 
correspond to relations, and nodes with a small circle correspond to operators. Dashed 
lines represent preconditions of operators. In Fig. 2 (a), cylinder Ji and step_circ_r are 
entities representing a feature of a mechanical part. This shows that the part has a circu- 
lar step. Ncjnachine and cut.circ.tool are also entities, but these are for manufacturing 
circumstances. 

On the other hand, processes such as cutjstep_circ and prepaxe_cut_tool are connected 
with these entities through relations and operators. For example, the relation has jstep.circj:, 
which represents that the cylinder has a circular step, is connected by the operator cut- 
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tingjstepxirc, so that the relationship between cutjstep_circ, cylinderji and step_circ_r 
is established. Because of understandability, Fig. 2 (a) omits primitives connecting with 
only one primitive. This diagram is a portion of a conceptual model of a problem. 

Fig. 2 (b) represents the same knowledge as (a), but it shows connections of all the 
computational elements, where entities and processes are eliminated. This diagram is 
used to automatically generate numerical expressions of constraints and causality to cal- 
culate the solutions. In Fig. 2 (b), each node has a parameter, while connections represent 
constraints or causality. For example, hcisjstep_circj: has one Boolean parameter and 
three constraints: cfaceju = cedgeju^ cface.d = cedgeju, and center Ji = center. h. The 
Boolean parameter is changed into true by the operator cuttingjstep_circ, if all its three 
preconditions: cylinder.exist, cutting_step_circ_dur and tooLprepared are valid. 



5 EXPERIMENTAL RESULT 

This section reports an experimental case study of a conceptual design. An interview 
with a designer of a target mechanical product is held to investigate what functions he 
considers during the conceptual design processes. After preparing primitives which can 
sufficiently represent the problem as vocabulary, an experiment of a problem solving is 
executed on PICCSS. According to the functional guideline described by the designer, a 
knowledge engineer execute the problem solving with the designer until a rough design 
and a rough manufacturing plan are obtained. 

5.1 Functional Sentences 

The product for the experiment is an aired pump, which drives using energy of com- 
pressed air. First of all, functions of the pump, in which various requirements and facts 
are associated, are described by the designer in Functional Sentences (FSs). These FSs 
were obtained through the top-down design processes. Some of FSs early in the refinement 
steps are shown in Table 3. 

In the conceptual design stage, the designer recognizes various elements of the problem 
by means of articulation in his/her mental world (Hori 1994). This articulation process 
occurs with terms in FSs, since any drafts of the product have not been obtained. Table 
3 describes that, the aired pump basically should be a machine which transfers slurry 
from the inlet of the manifold to the outlet of the manifold by compressed air. This FS 
is subject to the problem structure. Thus, the FS is not only a result of articulation, but 
also a result of problem clarification on PICCSS. 

To accomplish the top level function of the aired pump, sub-functions, which will satisfy 
the upper function, are considered. This top-down function refinement provides various 
FSs one after another. Sometimes, appropriate functions are retrieved from the knowledge- 
base, and sometimes they are given by the designer. After completing the experiment, the 
structure of FSs are established hierarchically following after Table 3. 

A rough sketch of the product is usually drawn by designers. This information is one of 
important results of conceptual design. Fig. 3 is a rough sketch of the case study in which 
various spatial information about the product is represented. This sketch was drawn by 
the designer during the interview. Note that these FSs and the rough sketch have not been 
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Table 3 Functional Sentences in the Conceptual Design 



level 


no 


upr 


functional sentences 


1 


01 


- 


Transfer slurry from the inlet of the manifold to the outlet of the 
manifold by compressed air. 


1 


02 


- 


Control the flow of slurry. 


2 


03 


01 


Transform compressed air into the flow of slurry by the diaphragm. 


3 


04 


03 


Get outlet pressure by the forward motion of the diaphragm. 


3 


05 


03 


Get inlet pressure by the backward motion of the diaphragm. 


2 


06 


01 


Make reciprocating motion of the diaphragm. 


2 


07 


01 


Keep the direction of the flow in the manifold. 


3 


08 


06 


Put two diaphragms symmetrically. 


3 


09 


06 


Supply compressed air to the air room when the diaphragm moves 
forward. 


3 


10 


06 


Release compressed air from the air room when the diaphragm moves 
backward. 


3 


11 


06 


Connect the two diaphragms by a shaft. 


4 


12 


11 


Transmit the forward motion of one diaphragm to the backward motion of 
another diaphragm. 


3 


13 


06 


Change the destination of the compressed air when the forward motion 
is finished. 


4 


14 


13 






slurry out 



^ slunyoui 



slurry in 



manifold 



slurry in 



Figure 3 Rough Sketch of the Product 
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completed before the problem solving is finished. They were actually obtained through 
the problem solving in step by step as results of the problem clarification. 

5.2 Design Parameters 

The quantitative requirements of the designer are given into the problem structure by 
substituting for the parameters. Some of the parameters are described definitely in FSs. 
The others are described implicitly in qualitative expressions. The values substituted for 
the parameters affect as maximum or minimum bounds through the constraint satisfac- 
tion. Of course, these design parameters may be changed with constraint relaxation, by 
modifying the requirements associated with these parameters. The constraint relaxation 
is performed considering the priority values of the parameters. 

The design parameters and their values are listed in Table 4. In this experimental case, 
the final level of the problem structure has 12 parameters which are necessary to calculate 
all of the spatial relationships on the draft. These parameters are already associated with 
the upper level of the problem. Thus, these values are regarded as not only the requirement 
of the designer but also the result parameters of the design problem, because they might 
be changed. For the present, default parameters shown in Table 5 also need to be defined. 
However, these default parameters will be omitted using some empirical knowledge on 
each particular problem. 



Table 4 Design Parameters 



ID. 


description 


value 


A 


distance between 


140 




diaphragms 




B 


diameter of plates 


56 


C 


thickness of plates 


5 


D 


stroke 


12.5 


E 


body width 


76 


F 


body height 


52 


G 


body inside width 


46 


H 


diameter of air hole 


3 


I 


distance of air holes 


12 


J 


diameter of shaft 


10 


K 


diameter of thread 


6 


L 


height of change block 


5 



Table. 5 Default Parameters 



ID. 


description 


value 


M 


slot depth of shaft 


3 


N 


thickness of slider 


2 


0 


length of slider step 


3 


P 


depth of slider slot 


4 


Q 


depth of change block 
pocket 


2 


R 


gap of change block and 
slider 


2 


S 


length of thread 


12 


T 


intersection of thread 


6 


U 


diameter of nut 


12 


V 


thickness of nut 


10 


w 


depth of nut thread 


8 



5.3 Top-down Refinement 

FSs are described by the designer in a top-down manner. This top-down problem re- 
finement is allowed by PICCSS, where the FSs can be replaced by primitives and their 
connections. Translating a FS to the representation form interactively, terms in the FS are 
selected in turn, and then, PICCSS retrieves and generates primitives which accurately 
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correspond to the terms. The indexes defined for each primitive are used to retrieve them. 
After generating the primitives in the computer, they are connected each other. 

In the refinement process, some primitives can be replaced by more detailed primitives, 
if the functions of these detailed primitives satisfy the functions of the upper primitives. 
Between these two refinement levels, the granularity of the representation and applicability 
to the real world are different. PIC CSS keeps the relationships over the two different 
refinement levels. Consequently, this top-down refinement process is performed supervised 
by the designer and the knowledge engineer. 

Fig.4 illustrates the problem structure in PICCSS in the early stage of the functicn 
refinement. This structure is corresponding to FSs from no. 01 to no. 07 of Table 3. 
First of all, the top level of the FSs: ‘Transfer slurry from the inlet of the manifold to 
the outlet of the manifold by compressed air’ is represented by ten hatched primitives: 
manifold_l, inlet _1, outlet _1, slurry.l, compressed_air-l, at_l, at_2, exist_l, transfer-l, and 
transfering_l. According to the semantics of the FS, these primitives are connected to each 
other. 

The first level of the functional representation drives the first loop of the main flow 
of CPS. Here, if there are some constraints or causality in the problem structure, the 
consistency management is executed. Then, the problem solving of the next level is carried 
out iteratively in the same way, until enough requirements and facts are clarified and there 
are no conflict nor inconsistency in the problem structure. In this experiment, the depth 




Figure 4 Initial Problem Structure 
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of the refinement level to clarify the problem is same as the level of the rough sketch 
shown in Fig. 3. 

When the refinement of the problem is terminated, most of the primitives in the final 
level are the registered primitives described in the previous section. Thus, the problem 
structure with these primitives can be calculated precisely to produce the spatial and the 
temporal structures. The final level of the problem structure of the pump is shown in Fig. 
5. This level hats more than 620 instances and more than 160 classes of primitives. The 
diagram of Fig. 5 is displayed by the Structure Editor, where relations and operators are 
drawn by their plain name and hatched name respectively. In this diagram, most of the 
primitives are omitted to display because of understandability. 




Figure 6 Spatial Chart (1-D Draft of Product) 



5.4 Problem Visualization 

The problem structure shown in Fig. 5 has various information about both a product 
shape and manufacturing processes. However, the information is contained by the unified 
structure of entities, processes, relations and operators, so that the designer hardly com- 
prehends the information. Thus, it is necessary to visualize the information through the 
PICCSS graphical user interfaces. Using this, the designer can evaluate the problem by 
investigating the solution candidates from some significant viewpoints. 
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Figure 7 Temporal Chart (Manufacturing Process Plan) 



Some visualized charts are obtained in the case study. Each of the charts is on a dif- 
ferent viewpoint. Two of these charts are illustrated in Fig. 6 and Fig. 7. First of all, 
Fig. 6 is a result of visualizing the problem structure from one of spatial viewpoints. 
This chart can be regarded as a single-dimensional draft of the product. Fig. 6 represents 
horizontal positions of some parts, e.g., the shaft (cylinder_h_l, tube_h>2, tube_h_3), the 
slider (tubeji.l, slot_circJi_l), the changing block (block_v_2, pocket_u_l), and the body 
(block.v.l, hole_through_v_l, hole_blind»d«l, hole_bline_d_2, pocket.d.l). There are an- 
other spatial charts, one of which represents vertical positions of these parts. Combining 
the horizontal chart and the vertical chart, 2-D product shape can be generated in order 
to send data to the conventional CAD systems. 

On the other hand. Fig. 7 is a temporal chart which represents a manufacturing process 
plan. Primitives listed on the left are processes, while the plots on the chart are opera- 
tors. Dashed lines connecting different processes represent their precedence. For example, 
inserting.! is a predecessor of inserting.2 and insert ing_3, which are again predecessors of 
inserting_4 and inserting_6 respectively. Precedence between two operators is generated 
by Constraint Manager in accordance with the causality of the operators. 

Using a common algorithm on Problem Visualizer, these various charts are visualized 
in order to evaluate the solution. In this case study. Fig. 6 and Fig. 7 were accepted for 
the final solution of the conceptual design. 
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6 DISCUSSIONS 

The proposed system and the underlying framework don’t provide knowledge of problem 
solving. They only provide a platform for problem solving. Thus, it is necessary to develop 
appropriate knowledge for particular problem domain. Because the evaluation for this kind 
of system is difficult, we discuss from the following five criteria. On each of these criteria, 
we evaluate our system to be one of four subjective levels made of excellent, good, minor 
and questionable. 

First, friendliness of the problem specification is minor. It is because the designer is not 
familiar with the connection-oriented knowledge representation. In particular, primitives 
without any instructions to use are too hard to be selected. Second, understandability of 
the display information is questionable. A problem, which consists of primitives and their 
connections, is generally difficult to understand. Thus, visualization technique should 
be applied more flexibly. Third, reusability of the registered knowledge is good. This 
characteristic is remarkable in lower level of the problem structure. In the experiment, 
75.0 % of the primitives in the final level are reusable. 

Fourth, correctness of the calculated results is excellent. Since the computer calculates 
accurately depending on the stored knowledge, capability of representing knowledge is 
much important. Thus, it is significant point that the proposed system allows the designer 
to represent knowledge from various aspects. Finally, appropriateness of the system scope 
is good. Particularly, it is remarkable that the early stage of product design is supported 
by the computer where top-down function refinement is performed. Even if the knowledge 
has different aspects and has not completely clarified yet, the proposed system can deal 
with the problem. 

In spite of informality of the knowledge used in the conceptual design, PICCSS effi- 
ciently dealt with the knowledge and allowed the designer to synthesize it. Consequently, 
it can be argued that PICCSS totally performs well in the conceptual design problem. 

There are some practical research for the conceptual design. However, the application of 
these research to the conceptual design in the real industry has not been popular yet. Thus, 
we discussed comparing the proposed system with one of the conventional representation 
methods, rough sketching. The comparison between the rough sketch of Fig. 3 and the 
solution provided indicates the following advantages of PICCSS. 



• PICCSS can explicitly deal with causality which produces behavior of the product. For 
example, the reciprocating motion of the shaft can be represented, where two states of 
the limit positions and the transition rules between them are defined. In the sketch, it 
is difficult to represent the state transition or the sequences of such a motion. 

• Manufacturing processes associated with products or parts are represented in PICCSS. 
Moreover, these manufacturing processes may not be fixed for each feature of the 
product, that is, alternatives can be described in the problem structure. This ambiguous 
representation gives capability to reorganize the plan in the following stages. 

• Functional descriptions are also put into the problem structure. In contrast to write 
them on the rough sketch, PICCSS keeps the relationship between the descriptions 
and some spatial or temporal features. These functional relationships represent some 
information about the refinement processes so that the design process knowledge can 
be reused as well. 
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In conceptual design, the hierarchy of FSs is an important result. In PICCSS, each FS 
is given by the designer, but it is strongly affected by PICCSS in concerning with various 
knowledge about a product and manufacturing. Capability for representing knowledge 
and efficiency of reusing the knowledge should be focused in evaluating the knowledge 
intensive CAD. 



7 CONCLUSION 

This paper, first, introduced the CPS framework developed for ill-defined problems such 
as conceptual design. To clarify the problem, the CPS framework has capability to assist 
a designer to articulate knowledge about requirements and facts. The main flow of CPS 
performs in a top-down manner so that functions, which associate the requirements with 
facts, are described hierarchically. There, this paper also showed that a spatial structure 
and a temporal structure of the problem are treated in a common platform. 

A conceptual design support system named PICCSS was then proposed. This system 
was implemented in the computer according to the CPS framework. In the experimental 
case study, requirements on the mechanical product were fragmentarily represented, and 
then, the problem to be solved was clarified. During the clarification of the problem, 
various constraints and causality were calculated until all the requirements and facts were 
satisfied. Finally, PICCSS provided a rough product draft and a rough manufacturing 
plan as a solution of the problem. 

In this problem solving process, PICCSS allowed the designer to synthesize his/her 
knowledge in the computer using prepared primitives. During this, the various knowledge 
was communicated between the designer and the computer. The experimental results 
showed that PICCSS performs well in the conceptual design in terms of knowledge inten- 
sive CAD. Furthermore, it can be argued that the CPS framework is much appropriate to 
this kind of problems because of its representation scheme and the calculation algorithm. 

In terms of knowledge intensive CAD, the advantages of the proposed approach provide 
some industrial expectations. The first is to shorten time of the design process by reusing 
valuable knowledge in the past. The second is to detect design failure by producing a 
rough manufacturing plan in advance, and the third is to take massive information for 
the conceptual design using the computer power. 

Many future works can be listed such as semi-automatic function refinement, acquisi- 
tion of template knowledge from the case-base, interfaces to CAD/CAM and CAPP, and 
support of collaborative product development. 
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Abstract 

The field of design science attempts to place engineering design on a more formal, rigorous footing. This 
paper introduces recent work by the author in this area. Artifact-Centered Modeling (ACM) is a general 
framework intended to partition the design endeavor in manageable sections. A fundamental part of ACM 
is the representation of information about products being designed. The Axiomatic Information Model 
for Design (AIM-D) is a formal theory about product information based on axiomatic set theory. AIM-D 
provides formal bases for quantities, features, parts and assemblies, systems, and subassemblies; these are 
all notions essential to design. It is not a product modeling system per se, but rather a logic of product 
structure whose axioms define criteria for determining the logical validity of product models. A previous 
version of the theory has been found to contain logical inconsistencies; the version presented herein 
addresses those problems. A complete axiomatization of the new theory is given, including a discussion of 
its validity. One of the obvious applications of AIM-D is in the development of knowledge-based systems 
for design. The author is currently implementing such a system using AIM-D as its foundation. The 
system, called Designer, provides the logical rigor of AIM-D within a computerized environment. At 
the user’s level, the system appears to be an object-oriented knowledge-base capable of representing 
information about all the kinds of entities represented in AIM-D. Although still under development, a 
discussion of the design and implementation plans for Designer is given. 



Keywords 

design theory, set theory, knowledge-based system, product information model. 



1 INTRODUCTION 



It is generally acknowledged in both academia and industry, that engineering design as an endeavor does 
not stand on as formal a footing as the engineering sciences, though it is unclear why this should be 
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so. The field of design science has emerged in response, to provide a more formal basis for design. The 
author’s interest in this area is in the use formal logic to describe the structure of design so as to facilitate 
development of reasoning processes for, and about, design. Such work can obviously find application in the 
development of knowledge-based (KB) design systems. The author’s current project is the development 
of (a) a formal theory of product models, and (b) to implement that theory in the form of a KB system 
for product modeling. It is important to distinguish the current work from many other efforts in product 
modeling. This theory does not provide a methodology for product modeling, but rather provides a logic 
of product structure. The axioms of the logic define criteria that must be met by any product model that 
is to be considered logically valid. This paper focuses on the author’s theory of product models, and its 
implications for KB systems. The implementation phase of the project is on-going research and will be 
discussed here only in relatively general terms. 

The current theory is a modified version of previously published work (Salustri and Venter, 1992), 
which (a) addresses a number of inconsistencies that have been detected since the original publication, 
and (b) expands the theory to include systems and features. 

The premise of the author’s research is that formal logic can be used to develop theories of design that 
are more robust than other, currently available theories, and that such theories will lead to representations 
and methodologies that will improve our collective ability to design high-quality, cost-effective products. 
The author has devised an overall framework to develop theories of the various aspects of the design 
endeavor; this framework will be presented briefly. While the overall work is not yet completed, this 
paper presents an important early result of the project: a theory of product structure derived from 
set theory. The theory is applicable in a number of areas, including the development of design process 
theories, curricula for teaching design, and computer-based tools to aid practicing designers. The focus 
in this paper is the development of computer-based tools. 

The rest of this paper is organized as follows. First, a summary will be presented of the overall framework 
of the author’s research. Next, the theory of product structure is presented, including its axiomatization. 
Then, a brief discussion of the validity of the theory is given, followed by a section discussing the use of 
the theory for the development of a KB system. After this, some extensions to the theory that are part 
of the author’s current, on-going research will be briefly discussed. Finally, some related research of other 
workers will be examined, and a concluding section will summarize the author’s findings. 



2 OVERALL FRAMEWORK 

The author has developed a general framework to partition the problem of describing design into man- 
ageable components. This framework, called Artifact-Centered Modeling (ACM), is shown graphically 
in Figure 1. ACM is developed from the premise that the engineered product should be at the heart 
of any modeling system intended to represent knowledge about design or designing. That is, a flexible, 
responsive enterprise should be able to tailor its organization to optimize its performance as well as the 
performance of its product(s); thus, the existing or anticipated product line is an essential input required 
to define the procedures and processes used by the enterprise. 

ACM partitions the overall design endeavor by abstracting both by function and by structure (or 
representation). These abstractions form the axes of a two-dimensional matrix of design aspects. In 
Figure 1, the horizontal axis is for function abstraction. The most concrete level on this axis consists 
of the functions to be provided by the product (its functional requirements), and by the manufacturing 
processes required to fabricate it (see the top left of Figure 1). The first abstracted level contains the 
functions provided by whatever design process is in use; these functions take the product’s functional 
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Figure 1 The artifact-centered modeling framework. 



requirements as inputs and produce a product design as their output. At the next abstraction level are the 
engineering management functions that synthesize, monitor, and maintain the design process functions. 

The other axis distinguishes four levels of representational abstraction. The most concrete level is 
that of systems: the product itself and the manufacturing equipment and processes needed to fabricate 
it. Once removed from this are models of the product and of the manufacturing system. At the next 
level of abstraction are languages that specify models (i.e. intentional descriptions of a set of possible 
models). Finally, at the most abstract level, are theories that justify languages used to model systems 
(i.e. intentional descriptions of sets of languages). 

The two most concrete levels of representational abstraction (the shaded regions in Figure 1) are 
particular to each group of design agents. This group of agents may be engineers working on a particular 
product, or an entire design office working simultaneously on a number of different projects. Each group, 
whether they know it or not, have particular systems and models ranging from the product line through 
to the mcinagement systems. The remaining levels of representational abstraction fall largely into the 
realm of research; work at these levels is generally concerned with finding new, fundamental, robust, and 
efficient ways of treating products, design, and engineering management. 

A variety of relationships exist between the elements of the ACM matrix, some of which are indicated 
by arrows in Figure 1. Obviously, theoretical developments affect the development of representational 
languages, which affect the kinds of models that can be developed with those languages and, in turn. 
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the designed products themselves. Similarly, engineering management systems affect design processes. 
But there are other relationships between ACM elements as well. For example, a design process affects 
the product model it produces. This is indicative of the effects that elements at one abstraction level 
have on elements at other abstraction levels. Also, the choice of language affects the design process that 
uses it. These relationships form a closed loop among the elements of the ACM matrix, which imply 
strong coupling between the various elements, and which make overall descriptions of design difficult to 
elucidate. However, the author believes that a systems approach, wherein individual elements may be 
treated as black boxes, can yield relevant and useful results. In particular, the author’s work takes the 
following stance: it is possible to develop theories for each element of the ACM matrix as individual items, 
so long as a clear vision of the expected interrelationships between elements is maintained. This is the 
main contribution of ACM: it captures the major aspects of the design endeavor at a coarse level, yet 
can indicate clearly the interrelationships between them. 

In addition to the decomposition of the elements of design by abstraction, ACM also assumes three 
operational perspectives of the elements represented in the ACM matrix. The structural perspective views 
the systems as artifacts produced by the design endeavor. The product itself is only one such artifact; 
in fact, every element of the matrix produces (possibly many) artifacts. The structural perspective deals 
with the representation of the form of those artifacts. 

Secondly, there is a behavioral perspective. This perspective treats a system as a black box capable 
of translating a set of inputs into a set of outputs, where the environment in which the black box 
operates is ’’transparent”. In this perspective, subsystems are synthesized into meaningful systems based 
on connecting outputs from one black box to inputs of another, independent of the internal workings of 
the subsystems. It is in this perspective that the interaction between a system and its general operating 
environment is defined. 



Environment 
[ System A 

JJ 



u- 






-LJ 



Environmern 




(a) Example Functional Perspective (b) Example Behavioral Perspective 

Figure 2 Perspectives in ACM. 

Finally, in the functional perspective, the system’s environment is opaque, but its internal structure is 
transparent. In this perspective, the specifics of the transformation from inputs to outputs is described. 
The functional and behavioral perspectives are depicted graphically in Figure 2. 

The distinction between behavioral and functional perspectives supports design processes that take 
advantage of functional analysis. At the initial stage of a new design, the behavioral perspective is used 
to study the environment and initial requirements of the design problem; these establish the overall inputs 
and outputs of the product to be designed. Once these inputs and outputs are established, the functional 
perspective is used to develop a transformation to produce the required outputs from the given inputs. 
The components of the system that provide the transformation are black boxes at this point. Note that 
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assuming a behavioral perspective from the point of view of an overall system (or product) is equivalent 
to assuming a functional perspective from the point of view of the elements of that system. By alternating 
behavioral and functional perspectives, a full functional breakdown of the design task can be synthesized. 
Further details regarding ACM can be found in Salustri (1995). 



3 PRODUCT MODELING THEORY 

Given ACM as described above, the next step is to begin filling in the details of the various elements of 
the matrix. The author’s first step has been to focus on the lower left region of the matrix - specifically, 
the development of a logic of product structure. 

A design’s state is assumed to be representable at an instant by a collection of information. The theory’s 
goal is to represent that information in a logically rigorous form. Also, a design process is considered as a 
sequence of actions leading from one logically valid state of information to another. If this is an acceptable 
view of design processes, then it is essential to have a solid understanding of the kinds of information 
present during a design process before the design process itself can be studied. This is the connection 
between the theory presented herein, about product structure, and design processes in general. 

3.1 Background 

The formal theory, called the Axiomatic Information Model for Design (AIM-D) is an interpretation of 
Zermelo-Fraenkel axiomatic set theory (commonly refered to as ZF) (Fraenkel et al., 1973). The goal of 
AIM-D is to provide a strictly logical framework for specifying information about a product at any point 
during its development. An interpretation of a ZF set theory is a mapping between the primitive entities 
in ZF 2 md primitive entities in the domain of product structure. The mapping establishes a semantics for 
the axioms of ZF from a design standpoint. 

There are two kinds of entities in ZF: individuals, and sets of individuals or of other sets. From the 
point of view of number theory, which has been classically the primary application of theories like ZF, 
it is possible to eliminate the individuals, thus allowing the hierarchy expressed by set membership to 
extend to both very large and very small sets. However, from a design perspective, this is not necessary: 
there will always be a point at which elements of a designed product can be considered primitive. So for 
AIM-D, we consider the primitive ZF entities to include both individuals and sets. 

Also, the author has found that not all the axioms of ZF are needed to describe product information 
formally. The axioms that have been found useful to develop AIM-D are those of identity, separation, 
foundation, power set, and union. 

3.2 Problems with the original theory 

Since its original publication, the author has identified some logical inconsistencies in AIM-D. Firstly, it 
was possible to represent an assembly. A, that has a part, P, such that both assembly and part had an 
identical characteristic, such as overall length, 1. Using the standard notation of set theory, this situation 
can be represented with the three statements: F € A, / € P, / € A. However, these statements violate the 
ZF Axiom of Foundation, which states that no member of one set that is also a set may contain another 
member of the one. This means that the situation above, natural and intuitive though it may seem, is 
logically inconsistent. 
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Secondly, some statements in the original theory were second-order in nature. For example, the use 
of explicit domains, which captured type information, took the form of statements about terms in the 
theory, rather than statements about the real objects those terms represented. Although there is a growing 
interest in second-order logics (Shapiro, 1991), first-order logics are far better understood, and have found 
to be largely useful in knowledge representation, artificial intelligence, mathematics, and computer science. 
Thus, it would be preferable to be AIM-D as a first-order logic. 

Thirdly, some kinds of entities clearly relevant to modeling geometry were difficult to represent. For 
example, if a spatial vector was defined as an entity, it could be used as a component of another entity, 
but not as one of its properties. But normal vectors of planes are better described as properties, rather 
than components, of the planes. Should vectors then be property values, or entities? 

These problems made it difficult to construct KB tools for design based on AIM-D, and needed to be 
addressed. A new development of AIM-D is given below that addresses all of these problems. 

3.3 Quantities 

ZF individuals are mapped to the most fundamental units of information that can describe quantitative 
information about products. In AIM-D, these units are called quantities and are tuples of numeric values 
and dimensional metrics; 5 feet, 200 MPa, and 10 ohms are all examples of AIM-D quantities. It is essential 
that dimensional information be embedded in the theory since without such information, quantitative 
entities are not logically comparable; that is, quantities must be ordinal values. 

We assume that a product model, M, contains a finite and countable number of quantities. This is a 
modest assumption, met by any realistic model, but that cannot be proved logically. Quantities map to 
ZF individuals, and any set composed only of individuals is a valid set since a set not containing other 
sets cannot violate the axioms. We can therefore define the following: 

Definition 1 All the quantities in a model, M, can be gathered into a set, called Q. 

Furthermore, the collection of values of all quantities, and of the dimensional metrics of all quantities, 
are each assumed to be finite and countable, and may be gathered into sets: 

Definition 2 The collection of values in a model M form a set, named V. 

Definition 3 The collection of dimensional metrics in a model M form a set, named D. 

This permits quantities to be defined formally as follows: 

Definition 4 A quantity, q, is a tuple and an element of the cartesian product of the sets V and D. 

Vg[(g eQ)-^ Bv3d[{v € V) . (d € D) • (g = {v, d))]] (1) 

A function of convenience is also defined, which maps quantities to dimensional metrics: for a quantity 
q, metric(g') is such that q = {v,metnc{q)). 

Finally, a set of primitive metrics is identified, from which all other metrics can be derived, according 
to the standard rules of dimensional analysis. In AIM-D, the following metrics are considered primitive: 
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• length (including angular displacement) • mass 

• time • temperature 

• voltage • amperage 

• cost • enumeration (for counting items) 

• NDU (non-dimensional unit - for ratios, etc.) 

This list includes metrics that are not typically considered in the physical and engineering sciences. 
Metrics are rational values invariant over any model of any product (e.g. a length is always a length). 
This fact will be used to develop the axioms of entity type, below. 

3.4 Design entities 

Individuals are collected into sets, sets of sets, etc. In AIM-D, these sets are called design entities (DEs). 
A product model is a DE that may be decomposed into other DEs until the level of quantities is reached. 

However, there are various levels between DEs and quantities where important kinds of non-primitive 
information arise. A product structure theory must treat these other information units as well. In AIM- 
D, there are four kinds of information: quantities, features, parts, and assemblies. Quantities have been 
discussed above; the other three levels are discussed below, and are all represented by DEs. 

Identity of DEs is defined by the straightforward application of the ZF Axiom of Identity. This yields: 

Axiom 1 (Identity of design entities) Two design entities, X and Y, are identical if they share ex- 
actly the same elements. 

(X = Y)=dfyx[{xeX) = {xeY)] ( 2 ) 

DEs can have a variety of kinds of elements. One kind of DE element is a property, which is an intrinsic 
characteristic of the DE. Most logics, and many KB systems and AI frameworks, take advantage of this 
notion. But, surprisingly, there is no clear, universal definition of what a property is exactly (van Dalen, et 
al., 1978). In our case, this is actually advantageous, since it allows us to define the concept without risk 
of violating the rules of logic. In AIM-D, it is sufficient to define a property as an intrinsic characteristic 
of a DE. Properties may have values that are either explicit - 5 feet, through-hole, spur gear, and stainless 
steel are examples of property values - or derived, in which case the value of the property is calculated 
based on other properties - for example, physical volume calculated from dimensions and shape. 

DEs are partitioned into sub-entities by various criteria that selectively include only certain elements. 
For example, given a product model, extracting information about shape yields a geometry model of the 
product. In AIM-D, this partitioning is achieved with views. A view is a subset of the elements of a DE, 
plus relations between those elements. The ZF Axiom of Separation is used to define views formally. 



Axiom 2 (Axiom of view formation) A DE, Y, that is a view of another DE, X, consists of all 
elements of X that satisfy a predicate 7. 

VX 3y[Va:[(a:ey) = (xeX). 7(x)]] (3) 

The predicate 7 is true for all DE elements that are in the relation that describes a view. For example, 
given a DE representing a four-bar linkage, and four instances of a relation freely-pinned, 7 would be 
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true only for the parts entering into the freely-pinned relations. The resulting view would contain the 
mechanical elements that are freely pinned to each other. Since Axiom 2 determines logically valid views, 
it also restricts the logically vcdid relations. The relations that Ccin be used in Axiom 2 are essential 
aspects of AIM-D. They may be considered constraints on the behavior of two or more DEs, or functions 
provided by the system modeled by the view and that cannot be provided by the elements of the view 
individually. It is unclear which perspective yields a more coherent theory at this time, but it is clear 
that both perspectives are meaningful and will have to be addressed. 

Views are not combined using set membership in AIM-D. That is, a view cannot have other views 
as members. Combining views is done with a set- wise union operation. Thus the union of all views of a 
product model is the product model itself. The ZF Union Axiom is used here. 

Axiom 3 (Axiom of view combination) A DE, X, is a composition of all the views containing ele- 
ments of X. 

\/X[3V[ix[{x ex) = 3v[(x ev)*{ve V)]]] (4) 

where X and x are DEs, v is a view, and V is a set of views. 

It is noted that valid views are subject to the Axioms of Separation and Foundation. Also, a given DE 
may occur in many views in V and still occur only once in X ; duplicate instances of a DE are identified 
through Axiom 1. 

3.5 Features 

The primitive physical entities in a product are the “atomic” parts that are assembled to form it. Castings, 
moldings, and machined items are all parts. However, part geometry information is needed when defining 
the exact physical relationships between them. The components of part geometry are reg 2 irded as features. 
It is evident from the literature that a universally accepted definition “features” does not exist; for 
example, the definitions used by Pabon et al. (1992), Rosen (1993), and Henderson (1993) are significantly 
different from each other. In AIM-D, features describe the geometric aspects of parts that enter into 
physical relationships. For example, information about the sides/edges of two plates is needed when those 
plates are to be welded together; the sides/edges are the anchor features at which the weld relation is 
associated. Features are distinct from parts in AIM-D in that features are not realizable (manufacturable), 
except as elements of parts. Features are the fundamental information units in AIM-D to which physical 
relationships are associated. Features may be values of part properties. It is noted that features are 
considered here only from a design perspective, although the manufacturing aspects of features are also 
very important. 

We assume there are a finite and countable number of features in a product model. 

Definition 5 The features of a model M compose a set called F. 

Features are formalized, using the ZF Axiom of Separation, as sets of quantities plus relations between 
the quantities. 
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Axiom 4 (Axiom of feature formation) A feature, f, is a DE that is composed of a set of quantities, 
each element of which satisfies a predicate a. 

3/[V9[(ge/) = (9€Q).a(9)]] (5) 

3.6 Parts and assemblies 

Parts are the primitive physical components in a product model. Though the value of one part property 
may depend on other property values (e.g. weight may depend on density and volume), they never depend 
on the values of properties of other parts. Parts are thus treated as DEs in AIM-D. 

Definition 6 The parts of a model M compose a set called P. 

An axiom for the treatment of parts as combinations of features may be written as follows. 

Axiom 5 (Axiom of part formation) A part, p, consists of all features, f, that are in F, and that 
satisfy a predicate (j). 

3p[V/[(/ep) = (/GF).0(/)]] (6) 

Parts are gathered into assemblies. Assemblies also have properties (length, mass, etc.). All assembly 
properties are derived from the properties of the assembly’s parts and are not intrinsic to the assembly 
itself. For example, though an automobile may be thought of as having mass, it is really the parts of the 
automobile that have mass. The automobile’s mass can be changed by changing parts, but the mass of a 
part is constant (assuming the part is not machined or otherwise altered in a way that alters its mass - 
in which case, one may argue that the original part not longer exists). 

The part/whole relationship is basic to how humans regard systems, natural or artificial, designed or 
otherwise. Mereology is the branch of logic that deals with this relationship. Mereologically, there is more 
to an assembly than just a collection of parts. That is, it is insufficient to simply lay out cill the parts of 
an automobile on the garage floor to have an automobile; the parts must exist in definite relations. 

In summary, an assembly (or part) consists of a set of parts (features), plus relations that exist between 
parts (features). This definition is consistent wiht that of a graph. The author expects that graph theory 
will play a significant role in the future extensions of AIM-D. 

Another mereological concept, that of subassemblies, introduces interesting complexities. The concept 
is relative: a subassembly may be treated as a part of an assembly, or as an assembly of parts. Its true 
usefulness in design is to form meaningful part aggregations that eliminate detail about a its components 
while preserving the essential characteristics of the aggregate itself. In other words, subassemblies are 
abstractions of collections of parts, useful as place-holders for information that is indeterminate in the 
early stages of a design process. Subassemblies are also very importsmt in manufacturing and assembly. 

Difficulties arise when considering relations between subassemblies. To say, for example, that an au- 
tomobile's engine is connected to its chassis, is true but vague. More precisely, we could say that there 
are pickup points on the engine block that are bolted to matching items on the chassis. The vaguer phras- 
ing is sufficient because the human mind can extract implicit information from it easily. But to support 
computer-aided reasoning with this kind of information, there must exist the means to capture the implied 
information explicitly. It is for this reason that we concern ourselves with these details here. 
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It is evident from this example that physical relations exist at the level of parts (or even part features) of 
subassemblies. Subassemblies may connect in multiple ways to achieve multiple functions. While sufficient 
information may be available to clearly define relations in structural terms late in a design, it is the goal of 
design to reach that stage. Since subassemblies are abstractions of part collections, the relations between 
subassemblies are abstractions of the relations between the assemblies’ parts. Since the form of the parts 
entering into a relation is unknown, the abstraction must depend on function. So relations between 
subassemblies will usually contain functional, rather than structural, information. 

This discussion motivates the perspective taken in AIM-D regarding subassemblies: while they are 
essential design concepts, they are not fundamental for logical product representations. Parts are the 
atomic components of a product, and assemblies represent the total product. A subassembly can be 
treated as a subset of the set of parts, plus the necessary relations. This allows the application of ZF to 
establish rules about what constitutes a logically valid subassembly. 

In fact, subassemblies are a kind of view in AIM-D. So, rather than treating subassemblies as parts 
that retain their status as parts when they are combined into an assembly, AIM-D requires that the 
subassemblies be broken open in the assembly, just as views are treated. The subassemblies may still exist 
as separate DEs, and may refer to the same parts as the assembly, but only the parts of the subassemblies 
(and the relations between them) are contained in the assembly. This leads to the following axioms. 

Axiom 6 (Axiom of subassembly formation) A subassembly, S, consists of all parts, p, that are in 
P, and that satisfy a predicate S. 

35[Vp[(p6S) = (peP).<5(p)]l (7) 

The predicate 6 is defined by the relation for a given subassembly. For example, in a freely-pinned 
connection between two parts, 6 specifies the parts (and fastener) that occur in the relation. 

Axiom 7 (Axiom of subassembly combination) For all assemblies. A, there exists a set of sub- 
assemblies, S, such that at every part in A occurs in at least one subassembly, s, in S. 

VA[3X[Vp[(p 6 A) = 3s[{p €«)•(«€ 5)]]]] (8) 

The notation U5 denotes the union of a set of subassemblies S. 

3.7 Systems 

There is another useful mereological structure: a system. Systems-based design is a popular paradigm, 
especially useful in the early stages of a design process, because a system, like an AIM-D sub-assembly, 
is an abstraction of a collection of functions to be provided by a product. In fact, a sub- assembly and a 
system are roughly equivalent. The definition given in Karnopp et al. (1990), which characterizes systems 
are (a) definitely distinguishable from their operating environment, and (b) composed of interacting 
parts, admits both sub-assemblies and systems. Where system components are connected functionally, 
subassembly parts are connected physically; so systems are actually more general. This means that a 
system is a collection of DEs that enter into some relation. This is exactly what an AIM-D view is; 
indeed, in AIM-D, the notions of systems and views are interchangeable. Thus the axioms that treat 
views also provide the required formalization for systems. 
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3.8 Type information 

The preceding section discussed mereological modeling in AIM-D. There is also, however, a taxonomic 
aspect that must be treated. A taxonomy is a structure used to classify items according to some set 
of criteria. Taxonomic information allows individual components to be identified, compared, and, often, 
referred to. The names of concepts for classes of things are often used to name individual members of 
those classes. For example, the sentence “The central gear is fixed to the axle” may refer to a specific 
individual gear and axle in a particular mechanism even though it uses the general concept names of gear 
and axle. Because this is obviously a very natural way to express design information, and because this 
kind of conceptualization forms the basis for a system of types of design information, it is very important 
to establish rigorous conventions for these concepts so that they may be treated logically. 

The mind maps real entities to conceptual names through generalization, which may be defined as 
selectively neglecting known dissimilar aspects of items in order to discover otherwise hidden or unknown 
similarities. This kind of information allows the intentional definition of entities, and is particularly 
useful to classify items based on conceptual notions that may change with time. Intentional information 
is treated directly by logics called description or term logics; these logics have provided the foundations 
for a number of KB systems that have found application in engineering, such as KIF (Hakim and Garret, 
1993) and CLASSIC (Brachman et al., 1991). This is one of the major advantages of KB technologies; 
intentional information is often unavailable, or at least difficult to provide and access, in other data 
modeling schemes. In order to formalize generalization, we must determine what kinds of information 
may be neglected. The author identifies three categories of information generalization: ignoring values of 
properties or parts, ignoring entire properties and parts, and ignoring the number of property or part 
values. Each of these is examined below. 

Information may be generalized by ignoring the values of properties and parts of a DE. The remaining 
information will only assert whether a DE has a given property or part. For example, we can assert that 
an automobile has an engine, but not what the engine actually is. This kind of generalization captures 
the notion of type, and is common in programming languages, information modeling systems, and KB 
and database systems. In this sense, two DEs are of the same type if corresponding pairs of attributes 
are of the same type. This is a recursive definition that ends at the level of quantities. So in order to 
axiomatize this kind of generalization, we must examine type-compatibility of quantities. 

In AIM-D, two quantities are type-compatible if they have the same dimensional metric, and two DEs 
are type-compatible if corresponding pairs of elements, one from each DE, are type-compatible. The 
predicate isa is defined to capture this notion; 



Definition 7 (The type-compatibility predicate) 

isa(g,r) =df (9 € Q) • (r € Q) • (metric(^) = metric(r)) (9) 

isa(x, y) =df Va[(a G a:)«!36[(6 € y) • isa(a, b)]] (10) 

where the notation !3 is read “. . .there exists exactly one. . .” (Bemays, 1968). 

By dealing with DEs in general, isa applies equally to features, parts, assemblies, subassemblies and 
systems. 

The set of parts, P, and the set of features, F, each can be used as the basis on which type-compatibility 
can be defined with the isa predicate. Using the Axiom of Separation leads to the following. 
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Axiom 8 (First axiom of generalization) Each part p in P, and each feature f in F, is exemplary 
of the members of a set S, all the members of which are type- compatible with p or f with respect to isa. 



Vp 35[Vx[(x € 5) = (x G P) • isa(x,p)]] (11) 

V/ 35[Vx[(x G 5) = (x G P) • isa(x, /)]] (12) 

where x is an exemplar representative of a number of other parts in the model; in other words, x is an 
exemplar of a type of part. 

This approach does not require explicit types and is thus first-order; it can accomodate a virtually un- 
limited number of simultaneous type hierarchies over the same set of parts, and requires no bookkeepping 
overhead associated with consistency maintenance of both types and instances. 

The second form of generalization involves the dismissal of whole properties. For example, a window 
may be defined as an item composed of a material that is transparent; all other properties are irrelevant 
to identifying windows. If a DE has a set of properties and a set of parts, then this kind of generalization 
involves identifying meaningful subsets of those sets. ZF’s definition of a subset can be applied directly 
here: any subset that satisfies the ZF Axiom of Separation represents a logically meaningful generalization 
of DE. Thus, each subset of a part is a generalization of that part, and thus is an exemplar of a swpertype 
of the part. Furthermore, the power set of a part p, V{x), contains all the possible supertype exemplars of 
p, and a set, S, can be defined to contain all the supertype exemplars of all parts in a product. Similarly, 
a set T of all possible supertypes of all features in a product can be defined also. 

Definition 8 (All Possible Supertype Exemplars of a Model) 

3S[Vs[(sGS) = 3p[(pGP).(sGP(p))]ll (13) 

3T[Vt[(tGT) = 3/[(/GF).(tGP(/))]]] (14) 

A new predicate is needed to relate supertype exemplars to parts. The predicate specializes, defined 
below, fills this role, and differs from isa only in the use of 3 instead of !3. 

Definition 9 (The Specialization Predicate) 

specializes(g, r) =df {q ^ Q) • (r ^ Q) • (metric(g) = metric(r)) (15) 

specializes (x, y) =df Va[(a G x) • 3b[{h € y) • specializes(a, 6)]] (16) 

Finally, the Axiom of Separation defines a generalization axiom relating supertype exemplars to parts. 

Axiom 9 (Second axiom of generalization) A supertype exemplar of apart (or a feature) of a model 
is a generalization of a set of parts (or features) in the model. 



Vs 

Vt 



35[Vx[(x G 5) = (x G P) • specializes(x, s)]] 
35[Vx[(x G 5) = (x G F) • specializes(x, t)]] 



(17) 

(18) 
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where s is an element of S, and t is an element of bf T, as defined above. 



It is also possible to define the inverse of specializes very simply as: generalizes(s,a:) = specializes(x, s). 

Not all subsets derived from the axioms above will be meaningful from an engineering perspective. 
That is, AIM-D is not used directly to generate reasonable generalized DEs of a given product; rather, it 
is a valuable tool to ensure that the DEs that are identified by a designer satisfy logical criteria. 

The third kind of generalization involves ignoring the number of values of a property, part, or feature. 
This is AIM-D ’s most significant departure from techniques often endorsed by the object-oriented tech- 
nology community. In an object-oriented environment, one might model an automobile with an object 
having an attribute for the number of wheels, and another attribute for the kind of wheels are to be used 
in a particular automobile. AIM-D, on the other hand, adopts the perspective taken by description logics 
used in knowledge representation, such as that proposed by Nebel (1990), wherein an automobile is be 
modeled as having wheels, and placing restrictions on the number and type of wheel “instances” in a 
particular automobile. The author prefers the description logic approach because it does not require at- 
tributes that have no corresponding manifestation in the real-world item being modeled (i.e. an attribute 
indicating the number of wheels). Rather, it allows values of properties, parts, and features to be grouped 
so as to make the same information available. In the sense that the resulting model corresponds more 
closely to the actual object being modeled, this approach is seen by the author as being more natural. 

A property, part, or feature of a DE may have a set of values, and the cardinality (size) of that set 
may be ignored or limited in order to generalize the DE. This permits a variable number of values for a 
property or part of a DE. For example, automobile engines can be characterized as having between 2 and 
4 valves per cylinder. In order to treat this kind of generalization, the number of elements in a set must 
be determinable: this is given by card(A), where A is a set. The predicate within is defined in AIM-D to 
determine if the cardinality of values of a property, part, or feature falls within a given range. 



Definition 10 (The cardinality predicate) For a supertype exemplar g and two integers i and j, the 
predicate within is true if the cardinality of all the attributes of a part p that are common to g have sets 
of values whose cardinality is between i and j. 

within(p,p,i, j) Va[(o £ g) • 3fe[(6 £p) *i < card(6) < j]] (19) 



This leads to the following interpretation of the Axiom of Separation for cardinality generalization. 

Axiom 10 (Third axiom of generalization) A part p or a feature f is an exemplar of a set of parts 
or features, each element of which has attribute value sets whose cardinality corresponds to the cardinality 
of the exemplar. 



V^ViV; 35[(p G 5) = (p € P) • within(p,p, i,j)] (20) 

VpViVj 3S[{f G 5) = (/ G F) • within(p, /, i, j)] (21) 



This completes the development of the axiomatic foundation of product model information with AIM- 
D. The theory integrates notions of quantities, parts, features, and assemblies, as well as subassemblies 
and systems, into a consistent system of logic for product models. 
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4 VALIDITY OF AIM-D 

Validity is a primary concern in all logical theories. A valid theory is one in which all true statements can 
be proved true within the system. While Goedel’s Incompleteness Theorem casts doubt on the validity 
of set theory and other useful systems of logic (Hofstadter, 1979), it is possible to show relative validity 
between systems. Specifically, there is a theorem of logic that proves that any extension of a system 
that introduces no new quantifiers, primitives, or connectives, is valid with respect to the original system 
(Copi, 1979). AIM-D is an extension of ZF set theory that obeys this restriction. Therefore, AIM-D is as 
valid a system of logic as set theory itself This is a fundamental result of the author’s work because it 
sets the foundations for structured and even automated reasoning about designed products with a degree 
of rigor unique in all the design research of which the author is aware. 

This is not to say, however, that any product model that satisfies the axioms of AIM-D is necessarily 
superior; there is no assurance that a model consistent with AIM-D will cost less, or be of higher quality, 
than other models. But this is not AIM-D’s purpose. Rather, AIM-D is intended to (a) identify logical 
inconsistencies in models, on the premise that improving the logical rigor of a model will improve its overall 
adequacy, and (b) specify information about product so as to allow their quantitative evaluation and 
comparison. This requires, in turn, that sufficient information about a design be represented (including 
cost, quality, etc.). Such models can then be analysed in a logically rigorous manner to determine their 
viability when compared to other existing models. 



5 APPLICATION OF AIM-D TO KNOWLEDGE-BASED SYSTEMS 

A detailed axiomatization of product structure based on set theory has been presented. The result, 
AIM-D, is valid with respect to its axiomatic foundation. An important application for AIM-D is in the 
development of KB systems for design. This section will discuss the author’s work in this area. 

Clearly, AIM-D’s notion of sets of entities can be treated computationally by an object-oriented technol- 
ogy. However, there are two significant differences between the author’s approach and that of conventional 
object-orientation. Firstly, type information in AIM-D is not explicit, which ensures that AIM-D remains 
a first-order theory. Most object systems, on the other hand, are class-based, having explicit structures to 
capture type information (for example, C-l--f- or CLOS), and may contain second-order information. This 
suggests that a computational system based on AIM-D should be based on prototypes rather than classes. 
Prototype-based systems have distinct advantages over class-based systems (Johnson and Zweig, 1991), 
especially in engineering applications; unfortunately, there are very few such systems, none of them having 
reached the maturity expected of a commercial product. Secondly, there are kinds of type information - 
such as classification based on the number of values of an attribute - that are treated differently in AIM- 
D. The author has attempted to reconcile these differences between AIM-D and object-orientation. The 
resulting system, called Designer, is implemented in the Scheme programming language (IEEE, 1991). 
Designer is intended to represent the state of product information at any point in its development, while 
satisfying the axioms of AIM-D. The language appears as a prototype-based, object-oriented program- 
ming language with limited multiple inheritance, generic functions, and a LISP-like syntax. Designer haiS 
been discussed in detail in other publications (Salustri and Venter, 1994, and Salustri, 1996). 

Although the author has had some success with the object-oriented approach, the resulting implemen- 
tation of Designer has been cumbersome to implement robustly, slow, and difficult to use. The author 
believes this is a result of the shortcomings mentioned above. 

Frame-based systems (Gonzalez and Dankel, 1993), on the other hand, exhibit characteristics that make 
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them more suitable as an implementation platform for AIM-D. Frames support prototypes, multi-valued 
attributes, and various operations on those structures, in a more flexible manner than typical object- 
oriented methodologies. They are commonly used in KB systems. Therefore, the author has decided 
to re-implement Designer taking advantage of frames, rather than objects. Scheme is still used as the 
implementation language, primarily for its succinct syntax, and the ease with which systems can be 
quickly prototyped. The new system is still under development, but some remarks regarding its features 
and capabilities are in order here. 

Frames in Designer model AIM-D design entities. They are also used for other implementation features, 
such as generic functions, but this aspect is hidden from the user’s view. AIM-D quantities are represented 
as separate data items. 

One essential difference between AIM-D and its implementation in Designer is that while the theory 
deals with the structures used to model products, its implementation must treat the naming of those 
structures. The issue would be relatively simple if Designer were intended for use by individual designers; 
but instead, Designer is intended to be used in collaborative environments including many designers. The 
issue of how the same things are named (identified) by different agents is an open problem in knowledge 
representation research, and there are a number of efforts intent on discovering its underlying logic (e.g. 
Capoyleas et al., 1996, Buvac et al., 1995, and Grove, 1995). The approach taken in Designer is fairly 
common in other KB systems: a context is defined as a mapping frame names to the frames themselves. 
Contexts may be nested; the outermost context contains various system definitions and represents a name- 
space containing universal concepts, and successive inner contexts become more specific to individual tasks 
and designers /users. Names can be reused in different contexts to denote different frames; this allows, for 
example, different users to name the same frame differently (or different frames the same). Although the 
problem of managing contexts effectively has not been dealt with yet by the author, the basic functionality 
as described here is well-defined as of this writing. 

All frames have explicit names in at least one context; there is a mechanism to automatically generate 
unique but meaningful names for frames created without an explicitly given name. Frames can be referred 
to by their explicit names, or by an indirect name composed of a path leading from some frame to the 
frame in question. For example, let car#22 be the explicit name of a frame representing a particular 
automobile, and let v8-3.51#127 be the explicit name of a frame representing the engine of car#22. The 
term (of engine car#22) is a path leading to the same frame as the explicit term v8-3.51#127. 

Relations are also represented by frames. For example, the definition of the term engine can describe 
it as a relation between car frames and engine frames; it describes the relation’s domain and range in 
terms of exemplars, according to the type axioms in AIM-D. The definition of engine can also describe 
it as a prototypical automobile engine. The definition used in each occurence of the term depends on 
the context that is current at the time the term is evaluated, and on the role assumed by the term in a 
statement. Thus, in the example above, engine occurs in the role of the name of an attribute of car #22; 
on the other hand, the role played by engine in a form like (of piston engine) is that of an exemplar DE. 

Although frames are used to represent quantities (Q), features (F), and parts (P) in a model M, it is 
not possible to enumerate all defined frames. However, it is possible to enumerate all members of each of 
the sets Q, F, and P, in a model; this allows the construction of algorithms that operate, for example, 
over all parts in a product model. It follows from AIM-D that a quantity cannot contain another quantity, 
a feature cannot contain another feature, and a part cannot contain another part. Similarly, features are 
composed only of quantities, parts may be composed of features and quantities, and assemblies may be 
composed of parts and quantities. These rules are all enforced by Designer. 

Designer stores type information by maintaining a specialization hierarchy. Internally, this is done by 
using a special relation attribute, specializes, whose value is a list of frames that specialize a given 
frame. The inverse relation, generalizes, is also maintained. The AIM-D type predicates isa, specializes^ 
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and within are all implemented as well. These attributes and predicates are used in situations where a 
user wishes to define an explicit specialization relationship. In addition to these explicit type-checking 
capabilities, Designer dlso allows type-checking by structural comparison of frames. For example, a frame 
4 is a specialization of a frame B, if all attributes in B have type-compatible counterparts in A; this 
procedure is recursive, ending at the level of quantities. These capabilities allow the system to find 
specialization relaionships that are not explicitly given by the user, and to verify that any explicitly given 
specialization relationships are consistent with the descriptions of the frames involved. 

The notions of views, systems, and subassemblies in AIM-D are all represented with DEs that are 
treated as subsets of other DEs. Views do not contain other views, and likewise for systems and sub- 
assemblies. There are exemplar frames for each of views, systems, and subassemblies, that are the roots 
of specialization trees; in this way, these kinds of entities are distinguishable from quantities, parts, and 
features. The algorithms used to create new frames make use of this distinction to ensure AIM-D ’s rules 
regarding views, systems, and subassmblies are obeyed. 

This discussion outlines some of the major features of the new version of Designer. Once completed, 
the new version, like its predecessors, will also include a library of generally useful frames representing 
common generic entities. Prom these generic libraries, other modules will be developed that will be 
particular to specific domains (e.g. mechanisms, pumps, motors, etc.). 

Designer clearly has limitations. For example, there is currently no way to associate a function with 
a part or assembly (i.e. no way to represent the fact that a certain part or assembly provides a certain 
function). There is no support for time dependencies, or for qualitative information (commonly found in 
the early stages of a design process). This is because there is as yet no logical infrastructure in AIM-D 
to support it. The language will grow as new theoretical developments are added. 



6 EXTENSIONS TO THE BASIC THEORY 

Although AIM-D fully describes the representation of structure in product models, there are a number 
of avenues that may be pursued to extend its capabilities even further. This section briefly discusses two 
areas that are of current interest to the author. 



6,1 Representation of function 

It is clear from even a cursory inspection of the current literature that the cost and quality of designs 
is most sensitive to changes made in the earliest phases of a design process, namely in conceptual and 
embodiment design. The author believes that these phases have been largely resistant to attempts at 
formalization, due in part to a relatively poor understanding of the function of products, and to how 
function maps to form. Although a number of research efforts exist - for example, IDEF-0 (NIST, 1993), 
and bond graph theory (Karnopp et al., 1990) - none has met with significant acceptance. This may be 
due to the somewhat arcane nature of the systems, or to the relatively restricted domains over which 
they operate. Nonetheless, this area continues to be investigated vigorously. 

If AIM-D is to be a universal logic of product models, it must treat functions of products and how 
those functions relate to the form of the artifact. The most primitive and abstract functions in electro- 
mechanical design are transfers of energy, of information, and of material (or mass). These are disjoint 
functions, and may be gathered into a set. A transfer occurs between two (or more) items, and thus is 
directed. The direction, location, and magnitude of these transfers are their basic properties. From the set 
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of primitive functions, and the ZF Power Set Axiom, and from relations between functions and entities 
that either provide, or are acted upon by, those functions, a hierarchy of more complex functions can be 
constructed. The author believes an axiomatization of function is possible, similar to the axiomatization 
of structure given in this paper. 

The basic transfer functions noted above are fundamental to design. But an artifact must provide 
other functions as well, functions relating to the needs and preferences of the customer or user, to 
maintainability, assembly, and manufacturing, to the corporate aims of the engineering enterprise, and to 
the environment in which the product is to be used. These kinds of functions have only recently attracted 
the attention of researchers, and much work remains to be done in this area. Although the author has 
not yet investigated the issue of function modeling to any depth, it remains a high priority for future 
research. 

6.2 Testing and analysis 

The axioms of AIM-D may be used as rules of logical integrity of information, from which algorithms to 
check information stored in a computer may be constructed. Other rules may be derived to automatically 
perform certain actions, such as classify DEs. Three examples of rules deriving from the axioms are: 

1. No entity may contain both features and parts; if this were possible, then the ZF Axiom of Foundation 
would be violated (in the general case), resulting in an inconsistent product model. 

2. A subassembly is identified by a relation. Without that relation, there is no way to distinguish between 
elements of the subassembly, and other DEs. Therefore, no subassembly may be formed without first 
defining an appropriate relation. 

3. The axioms of generalization are classification criteria that can partition a set of DEs into subsets 
based on similarities between corresponding elements from pairs of DEs. This means it is possible to 
automatically classify any DE and, for instance, insert a new DE into a hierarchy of existing DEs. 

Additionally, other validity checks may be performed by using the axioms as the basis for inference 
algorithms. Deduction is the classiccd inference technique of logic, and may be used with AIM-D ’s axioms 
as well. The rules of deductive inference allow a variety of theorems (statements whose truth is not known) 
to be either verified or denied through application of the axioms. However, it is evident that deduction 
alone is not enough to support the myriad actions that may be performed on product models in the course 
of a design process. There are occasions when induction or abduction may best represent the actions being 
performed. 

As AIM-D matures, the author will begin to investigate how the various inference techniques can be 
applied best to produce algorithms to (semi-) automatically check the validity of product models. Such 
verifications could significantly improve a designer’s ability to justify a design on logical grounds. 



7 RELATED RESEARCH 

It appears that the original impetus to treat aspects of design logically arose from the need to provide 
computer tools to aid the practicing designer. Theories of geometric modeling were developed to support 
computer-based graphics and, eventually, solid modeling systems. In the end, the theory of geometric 
modeling became its own field of study. Similarly, with the realization that artificial intelligence research 
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could play an important role in engineering, researchers began to regard logic as a means of formalizing 
engineering knowledge. It is not unexpected, then, to find that much of the research most closely related 
to AIM-D comes from the computational fields. 

Description logics, such as those underlying KIF and CLASSIC, have certain points of interest in 
common with AIM-D; this has already been discussed. However, these logics are targetted to the gen- 
eral problems of knowledge representation, and, unlike AIM-D, are not intended to treat the particular 
requirements of engineering. Logical foundations are also present in a number of other computational 
systems. For example, the EDM data model of Eastman et al. (1991) is directed to the construction of 
databases for product modeling using logic; SUMM (Fulton, 1992) attempts to provide an underlying 
logic based on the predicate calculus for the PDES/STEP product model initiative; and the logic-based 
expert system developed by Jaluria et al. (1991) is directed at a particular design task. None of these 
efforts fill the role that AIM-D is designed to fill, namely, to provide a foundational understanding of the 
product itself, rather than models of those products. 

Logic has also been applied to the development of other abstract systems that are relevant in engineer- 
ing. Examples include the development of constraint theory (Friedman and Leondes, 1969), the topological 
aspects of feature-based design (Rosen and Peters, 1992), systems for cooperative design (DePaoli and 
Tisato, 1994, and Polat et al., 1993), and language-based systems for design (Ward, 1992). These efforts, 
though relying on logic to an extent, do not preserve the degree of rigor afforded by AIM-D; their validity 
is therefore suspect (from a logical perspective). 

Finally, logic has been and continues to be used as a fundamental means of studying design in a 
purely abstract sense. Examples of this include Bijl (1987), Suh (1990), and Roozenburg (1992). These 
efforts, among others, focus primarily on the processes of design, rather than on the formalization of the 
informational content associated with those processes. 

In light of the forgoing review of related research, the author suggests that AIM-D straddles a number 
of different existing design research arenas. It is well-suited to computational developments; this has been 
a key focus point. But it also preserves a level of abstraction suited to academic research, and though it 
focuses on product information, it may also find use as a foundation upon which to build process theories. 



8 CONCLUSIONS 

This paper has introduced AIM-D, the Axiomatic Information Theory for Design, a theory able to describe 
the structure of designed products in a logically rigorous manner. It is not a product modeling system in 
itself, but rather a logic of product structure whose axioms define criteria to determine the logical validity 
of any product model. The previous version of AIM-D exhibited certain logical difficulties that have been 
resolved in the version presented here. AIM-D is based on axiomatic set theory, and is demonstrably 
valid with respect to set theory. It handles quantities, features, parts, and assemblies, as well as systems 
and subassemblies, all very important notions in describing products. It is not intended to automate any 
part of designing per se, but to provide a framework for designers to think about design problems in a 
more structured manner and to form the logical foundations for tools to aid designers in their daily tasks. 
Vis-a-vis this laist issue, this paper has also discussed how AIM-D is being used to develop Designer, a 
KB system intended to represent product information in a computerized form. Designer draws from both 
object-oriented and KB technologies; the operations possible in Designer satisfy the axioms of AIM-D, 
and thus preserve the logical structure of the theory. 

AIM-D is not a closed theory; there remain a number of possible extensions that may be added to the 
language. If AIM-D is to ever be a universal theory of design information, then these extensions will have 
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to be addressed. The most important extensions, currently under development by the author, are the 
incorporation of function, and the ability to validate product models. As part of ACM (Artifact-Centered 
Modeling), AIM-D forms the foundation of a theoretical development that will eventually cover all aspects 
of the design endeavor, including design processes, and enterprise modeling. 
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Abstract 

In this article an approach is shown to support knowledge intensive engineering along the product-life-cycle. The 
approach supports the design of complex products by the concept of design working spaces. A design working 
space is an eucledian space and builds the framework for a methodological decomposition of complex design 
problems into sub-problems. The sub-problems are evaluated by a knowledge based design system which is flexible 
and evaluates problems along the product-life-cycle phases. With an example we describe the knowledge based 
design system for knowledge intensive design activities. 
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1 INTRODUCTION 

Product development as a whole becomes an important factor for the industrialized nations. It becomes more and 
more difficult to meet the customers' demand and to compete on the international markets with high quality and 
good value products, which have to be produced faster and faster to cut down the time to market. A product passes 
several product-life-cycle stages during its life time, beginning at the Product Planning phase and ending up when 
the product will be recycled ( Figure 1 ). 

All stages have a strong interrelationship and therefore it becomes more and more important to cover all these in- 
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Figure 1 The Product Life Cycle 



terrelationships in an integrated product model. In addition to this an integration along the product-life-cycle stages 
requires both a logically integrated product model as well as modeling methods to work with an integrated product 
model. Products become more and more complex and therefore modeling methods have to handle the product com- 
plexity as an important requirement they have to meet. An important factor in the product-life-cycle is the product 
design because here all characteristics of the future product is determined. First we give a short overview of the 
design process (Section 2) and discuss the informations that are necessary in a logically integrated product model 
for designing technical artifacts (Section 3). In Section 4 we introduce the concept of design working spaces as a 
basis for the decomposition of complex design problems to prepare the decomposed and structured problems for 
solving it by an integrated knowledge based system (Section 5). At the end we describe the architecture (Section 
6) with which we implemented our ideas and verify the concept with an example (Section 7). 

Before stepping into more details we direct some interest on a design serving as an example to explain our ideas. 
In Figure 2 there is shown a robot gripper designed for handling small parts, for durability and for low maintenance 
costs. A standard connection to the robot arm as well as the space in which the gripper has to fit is given by the 
product requirements. The working method of the gripper is as follows: The force with which the handled part is 
gripped is generated by an pneumatic energy source. The resulting force is then transmitted through a piston rod to 
a wedge splitting the force into two resulting forces which are applied to the grippers jaws. The applied pressure 
causes a movement of the piston rod towards the jaws and therefore the wedge causes a turning motion of the jaws 
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which results in the gripping force of the robot gripper. The detachment of the handled product is realized by a 
spring (not depicted) and by reducing the pressure applied on the piston. So the spring pushes the piston back to 
it's original position. 




Figure! Product Example 



2 OVERVIEW OF THE DESIGN PROCESS 

The design process is considered in an idealized manner as a successive concretion of the description of the to-be 
characteristics of a technical object [2],[1], [3] a. o. This concretion process takes place on the product modeling 
level. Koller, Pahl, Beitz, Roth and other design methodologists define this process to lead from the incomplete 
to the complete^ the abstract to the concrete^ the rough to the precise, the provisional to the definitive and from 
possible alternatives to the optimal solution. 

Typical for the design process is the successive growth of the set of design characteristics with respect to the 
current state of the design. Here design characteristics are defined as the instantiated solution properties of a product 
to be developed. The sum of all these solution properties determine the overall behavior of the product in real life. 
The description of the solution properties is the result of the design phases in the design process that consists of 
defining the requirements of a product, the definition of the functional structure and the function flow within a 
product, the description of the physical effects which can be assigned to the respective functions in correspondence 
with the modeling of the product's effective geometry and the embodiment (Figure 3). 

In each phase a general problem-solving cycle has to be performed ( Figure 3) which can be derived from the 
psychology of problem solving [4]. In this problem-solving cycle the designer is first confronted with the problem. 
Afterwards the definition of the essential problem is performed by fixing the objectives, main constraints and 
the environment for the intended solution. The next step is finding and representing the solution for the defined 
problem. After that the solution has to be evaluated followed by making a decision. Finally as the following step 
the problem-solving cycle is reiterated. Each established solution serves as a supposition for the next problem 
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^|bd8!^ng of product requirements 




Figure 3 Modeling Layers in the Design Process for Technical Products 



respectively the next design stage. In this way, the designer proceeds from the qualitative to the quantitative, from 
the abstraction to the concretion, from the incomplete to the complete etc. The general problem solving cycle 
is together with the design stages of the design process, the basis for the informations needed to solve design 
problems. 



3 THE MODELING LAYERS IN THE DESIGN PROCESS 

The result of the design process is a model of an artifact. With the three fundamental magnitudes of design, 
matter, energy and information every artifact technical system can be described on an abstract physical level [3], 
[1]. A technical artifacts is embedded in the environment by means of input and output and can be treated like a 
system. A system can be divided into sub-systems. What belongs to a particular sub-system is determined by the 
system boundary. With this approach it is possible to describe every technical system at every stage of abstraction. 
Describing a proposed technical artifact by means of a system consisting of elements, which are grouped by the 
system boundary related with each other by input and output, we use the term function or product function. If the 
input and output of the product function is described on the basis of matter, energy and information then we use 
the term general function. If the inputs and outputs represent pAysica/ magnitudes like force F or torque D and the 
relationship between the in- and output is described by a limited set of function verbs, then we use the term special 
function. The function verbs describe the proposed transformation between the input and output on an conceptual 
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level. With reference to Roth (1994) we use the set of function verbs Change, Connect, Channel and Store. In the 
case of relating the in- and output by a physical law that is described by a mathematical equation then we talk about 
an established physical principle. All technical artifacts are complex constructions, so every artifact is described 
by a general function structure, a special function structure and a physical principle structure. In accordance to 
the phases of the design process of Figure 3 the logical modeling layers can be been defined as follows: 




Figure 4 The Task Structure of the Robot gripper 



REQUIREMENTS MODELING LAYER 

The requirements modeling layer serves for the computational projection of the results won by the clarification of 
the design task. This modeling layer contains the preconditions of the design, the to-be properties of the future 
product and the description of the product's immanent task structure. The Task Structure is defined by a noun and 
a limited set of task verbs. 

Figure 4 shows an example of the product task structure* of the robot gripper from Figure 2 . First the designer 
has to establish the main task the product has to fulfill. In the example the designer has to develop a device 
that is able to handle work pieces. The designer gets the information to form the “main task sentence” from the 
customer or the product planning stage. In the following the main task has to be broken down into sub-tasks. This 
can be done manually or automatically. An automatic derivation has to be done by so called process pattern [5]. 
This modeling layer is finished when the designer has modeled elementary sub-tasks, so that a transition to the 
functional modeling layer. 

FUNCTIONAL LAYER 

Functional modeling serves for finding and describing the functions of a design solution as well as the functional 



*The English sentences in the example are badly formed because the design system DIICAD Entwurf is developed 
for a German syntax structure 
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Figure 5 Modeling Structures of the Robot gripper 



interrelationships within the future product. Functional modeling allows the definition and manipulation of func- 
tions on different levels of abstraction. The logical transition and by that the concretion of the functional model 
to the physical principle model is supported by the specification of the vectorial functional structure. Figure 5 (1) 
shows the established special function structure of the robot gripper ( Figure 2 ). On this level there is seen that the 
energy type pressure (input) is changed in the energy type force. After that the force is channeled, distributed and 
amplified (output). 

PHYSICAL PRINCIPLE MODELING LAYER 

The physical principle design serves for the description of the solution principle of a special function. It covers 
all informations of the product’s physical solution. These informations contain the physical effect that is described 
by a mathematical equation and geometrical informations as effective lines, effective surfaces and effective spaces. 
In Figure 5 (2) there is depicted the established physical principle structure and the derived effective geometry 
( Figure 5 )(3) of the robot gripper. 

SHAPE MODELING LAYER 
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The shape modeling is the most concrete one of the product modeling layers. In this layer the design process is 
completed by the geometrical definition of all design features, parts and assemblies. 

To model complex products there is still a lack of modeling methods which helps to structure the product 
informations in order to reduce the complexity of the subtasks. With respect to this problem and focusing on the 
evaluation problem we introduce the concept of ’’design working spaces” which is described in the next section. 



4 DESIGN-WORKING-SPACE 

A design-working-space is an Euclidean space available for the designer to solve his design task. The design- 
working-space is defined by an envelope (geometric system boundary) and its constraints (in-/outputs) (see defi- 
nition of the dws). The fundamental idea comes from system theory and is therefore not limited to the geometric 
scope. The main purpose of design-working-spaces in this context is to integrate the design stages and to decom- 
pose a given design problem into solvable subproblems. 

In Figure 6 there are three design- working-spaces which have to fulfill a special product function, like “change 
force into torque” ( Figure 6 ) (2) or “amplify force by force” ( Figure 6 ) (3). The system boundary of a design- 
working-space is clearly defined by its maximum envelope, effective geometry and by the physical in- and outputs 
like the physical magnitudes force F\ and torque Di ; the envelope and the effective geometry is represented by 
free form surfaces. The envelope describes the maximum space inside which a special problem has to be solved. 
The effective geometry is described by effective spaces and effective surfaces which transmit for example forces. 
The relationship between the design-working-spaces is established exemplary by the general magnitude energy E 
and the special magnitudes force F 2 and torque D. 
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Figure 6 Concept of the Design Working Space 



Design-working-spaces will be builded up by the following rules: 
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1. A design-working-space consists of a set of elements and of a set of relationships between the elements. 

2. Elements of a design-working-space are informations of the design stages, like product requirements, func- 
tions or physical principles. Relationships between the elements are general or special magnitudes like energy, 
information, matter or force, torque etc. 

3. Every design- working-space can be subdivided into independent sub-spaces. If elements of different sub-spaces 
will be grouped together then this sub-spaces are called overlapping design-working-spaces. 

4. Every design-working-space and every sub-space is defined by a system boundary. The system boundary is 
specified by its envelope, making available the maximum of geometric space for the design and its effective 
geometry. The effective geometry defines the point at which the physical phenomena takes place. 

5. A system boundary of a design-working-space has one or more in-/outputs. If a design-working-space has no 
in-/outputs then we talk about a closed design-working-space, on the other hand about an open design-working- 
space. 



5 DECOMPOSING AND EVALUATING DESIGN PROBLEMS BY 
DESIGN WORKING SPACES 

During the design process it is typically that the designer is permanently changing the scope of design to evaluate 
the design which depends on a certain context [4],[3]. An example of a gear box design is shown in Figure 7. 
During the design process the designer changes the view on the design by clipping and zooming the drawing area. 
The necessity is obvious because on one hand the overall gearing box on the other hand the detail of the bearing 
is important but both have to match the requirements regarding size, function, general arrangement, spatial com- 
patibility etc. In all this, technological, economical and other considerations are of paramount importance, so that 
the designer needs to have modeling methods to structure the scope of design to evaluate the design according to 
different criteria. The scope of design covers all aspects including the product task, the product function, principle, 
effective geometry and must not limited to the embodiment stage as shown in Figure 7. 

Modeling methods which meet the required functionality discussed above involve a large number of corrective 
steps in which analysis and synthesis constantly alternate and complement each other. This explains why the famil- 
iar methods underlying the search for solutions and evaluation must be complemented with methods facilitating 
the identification of errors (design faults) and optimization. The collection of information on materials, manufac- 
turing processes, repeat parts and so on is complex and requires a considerable effort: many actions have to be 
performed simultaneously, some steps have to be repeated at a higher level of information. Without having struc- 
turing methods it is not possible to evaluate complex products and it is impossible to evaluate complex products 
with respect to different criteria. 

For that, a complex problem has to be defined, broken down into sub-problems until these sub-problems can be 
evaluated. Figure 8 shows the idea. There is given an overall problem which cannot be evaluated because it is too 
complex. The idea is to identify and to mark off the critical sub-spaces. A sub-space is a critical sub-space if the 
complexity of an overall problem can be reduced in a large amount. After having solved all critical sub-spaces the 
designer can go back to the overall problem to solve it again. 

With the help of Figure 8 we summarize the elementary steps that have to be performed in this process. First 
there is given the overall problem that has to be broken down into sub-problems. This step has to be repeated until 
an elementary problem has reached. This elementary problem is evaluated and solved. After that the sub-problem 
should be evaluated on a higher level by evaluating the relations (constraints) between the solved elementary 
problems while regarding the elementary problems as a whole. These steps have to be repeated until the overall 
solution is evaluated. 
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Overall Layout Detail 




Figure 7 Broadening and Reducing the Scope of a Gear Design with the Example of a Technical Drawing 
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Figure 8 Decomposition an overall problem space into sub-problem-spaces 




88 



Part One Architecture for Knowledge Intensive CAD 






1 



2 . 



3. 

4 . 

5 . 



6 . 



Overall‘Pr6blem 



SuthProbtem 



Elemenlary- 

Problem 

Evaluated 

Elemalary- 

Solution 

Evaluated 
Sub- Solution 



Evaluated 

Overall 

Solution 



Figure 9 General Evaluation Process for Evaluating Designs 



6 THE ARCHITECTURE OF THE DESIGN SYSTEM DIICAD 
ENTWURF 

The following section describes a part of the integrated product model used in “DIICAD Entwurf’t for the evalu- 
ation of design principles^ with design working spaces. The section is divided in two subsections. Subsection 6. 1 



^D/alog oriented /ntelligent CAD System, Entwurf is a subsystem for Design Space Modeling 
^ Design principles have been discussed at some lenth in literature. We refer to Pahl and Beitz [1], who distinguish 
among other things Principles of force transmission like “Flowlines of force and principle of uniform length”, 
“Principle of direct and short force transmission path”, “Principle of matched deformations” and “Principle of 
balanced forces” 
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describes the object oriented product model serving as the knowledge base. Subsection 6.2 describes the imple- 
mented rule base for the design principle “Force transmission”^ which is used in the the example. 

Figure 10 shows the Architecture of the design system. The System is devided in three parts: the Graphical 
User Interface, the Design Modeler and the Object Oriented Database. The Graphical User Interface, the Design 
Modeler and the Application Programming Interface (API) to the Database and the Geometric Modeler is written in 
itcl^, except from the knowledge base that is written in CLIPsH . As geometric modeler we used Pro/ENGINEER 
that is controlled by the Design Modeler with ProDEVELOP§ **. 

The Design Modeler consists of two parts ( Figure 10 ). One part is the Design Working Space Modeler and the 
other one the Knowledge Based System. The Design Working Space Modeler consists of 5 Modules to model the 
informations of the modeling layers discussed in section3. The Knowledge Base is logically divided in a Knowledge 
Acquisition and an Interpretation Module. Logically means that these two “modules” can be distinguished but they 
are incorporated in one rule clause (see Section 6.2). 




Figure 10 Architecture of the Design System DIICAD Entwurf 



§ According to Pahl and Beitz [1] Force transmission means “Principle of direct and short force transmission path” 
^itcl provides object-oriented extensions to Tcl, much as C++ provides object-oriented extensions to C 
II CLIPS is an expert system tool developed by the Software Technology Branch (STB), NASA/Lyndon B. Johnson 
Space Center. CLIPS is designed for writing expert systems. 

** ProDEVELOP is the programmable interface to Pro/ENGINEER 
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6.1 The Information Model 

The following section describes the information model implemented in DIICAD Entwurf. The classes consist of 
object attributes, object relations, object methods and class functions. Only the important object methods and class 
functions will be described. 

An object relation is always bidirectional, e.g. if a relation named requirement was defined from a DesignContext 
object to a Requirement object there will be an implicit relation named requirement from the Requirement object 
to the DesignContext object. Such a relation can be read as “a DesignContext object has a requirement (which is a 
Requirement object) and a Requirement object is a requirement of a DesignContext object”. 
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Figure 11 Information Model of the Design Context 



The DesignContext is the central class of the model ( Figure 1 1 ). It is mainly used to group instances of other 
classes to form the context of a design problem. DesignContexts are able to group themselves to split the problem 
into subproblems that can be solved independently. A found solution can be joined together to form the solution of 
the higher context. A DesignWorkingSpace object is always related to a DesignContext and defines the geometric 
boundary of a design problem. 

A ProductTask object defines the task the product has to fulfill. A PrvductTask is defined by a noun and a verb 
(Figure 12). The noun can be chosen freely, the verb has to be one of a list of predefined ProductTaskVerb objects. 
The context of the design problem is defined by the related DesignContext object. 

A Requirement object is always related to a DesignContext ( Figure 11 ). It defines the product requirements that 
have to be fulfilled by the solution of a design problem ( Figure 12) . The related Person object specifies the claimant 
of the requirement. If a physical magnitude is specified as a quantitative requirement, a Units object is related to 
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Figure 12 Information Model of the Product Task 



define the minimum and maximum values. The requirements for the solution of a design problem can be classed 
by their scope. The RequirementScope defines the accepted requirement scopes, for example costs. 

The PhysicalMagnitude objects define the physical magnitudes by the attributes of name, units, symbol and 
type. 

The PhysicalMagnitudelnstance ( Figure 14 ) defines the interface of a DesignContext. A PhysicalMagnitudeln- 
stance can be related to a DesignContext as its input or output. This relation defines the “direction” of the “function 
flow”. The PhysicalMagnitudelnstance has a relation to a PhysicalMagnitude. The PhysicalMagnitude describes 
the physical magnitude itself whereas the PhysicalMagnitudelnstance object describes the interface to a Design- 
Context with its relation and attributes. 

A Unit object defines a unit by its name and the mathematical combination of base units. Only base units are 
known to the system but if a PhysicalMagnitude object has to be defined which has no base unit, it is possible to 
define a new unit by the combination of base units with the Unit object. 

A SpecialFunction defines a special function consisting of an input, verb and an output. The input and output 
are relations to PhysicalMagnitudes, the verb is a relation to a SpecialFunctionVerb that is a list of accepted 
verbs for a special function and describes the relation between PhysicalMagnitude input with the result of its 
PhysicalMagnitude output. 

A SpecialFunctionInstance is part of a design solution for a problem defined by a DesignContext. Its verb and 
type of the inputs and outputs are defined by its related SpecialFunction. The type of a function distinguish between 
a main and an auxiliary function. 

A PhysicalPrinciple object defines a physical principle by its name and physical law, which is specified by 
a mathematical equation. The related SpecialFunction objects define the supposition for the use of the physical 
principle. 

An EffectiveGeometry defines the geometry where the physical phenomena, described by the PhysicalPrinciple, 
takes place. The designer may modify the parameters of the effective geometry within its constraints and use 
methods to derive the geometry of the SolutionElement. 

The SolutionElement object defines the geometry of a solution for a design problem ( Figure 15 ). 

A Task object defines a task for a designer and grants explicit permission to view and modify those parts of 
the design problem that it refers. A Task can suppose other tasks to be completed first, i.e. Task objects perform 
sequential control upon the design process. 

All the people involved in the design process are known to the system as Person objects. A person is defined by 
its name, login, password and authorization. 
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Figure 13 Information Model of the Requirement class and its related classes 



Each Person object (general databases class) has a related Preference object that holds user specific preferences, 
e.g. the path to the working directory or the desired view on the geometry. 

Like the Preference object a Coordinator object (general databases class) is related to every Person object. The 
Coordinator object coordinates the designers within one project. It has relations to the current Project object, Task 
object and DesignWorkingSpace object of the related Person object. 

A MaterialType object defines a material type. It is used to class Material objects. 

A Material object (general databases class) defines the Material type and all of its properties. 

6.2 The Knowledge Base 

This section describes the complete rule base for the design principle “FORCE-TRANSMISSION”. The rule base 
contains more design principles than only “FORCE-TRANSMISSION” but this design principle is the simplest 
one, can described completely and shows the idea of the concept. 

The module FORCE-TRANSMISSION describes all rules that are able to detect whether the design principle 
“FORCE-TRANSMISSION” can be fulfilled or not. The rule base extracts the the facts from the product model 
by the API over a piping mechanism. If it is not possible to derive or to extract all facts from the product model 
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Figure 14 Information Model of the Product Function and their Structure 



an user interaction takes place. In this case the user is asked to enter the missing facts which are instantiated in the 
product model (knowledge acquisition). According to a certain design principle an incomplete design is becoming 
complete. 

(defmodule FORCE -TRANSMISSION 
(export ?ALL) 

(import MAIN ?ALL) ) 

Module for the Evaluation of FORCE-TRANSMISSION 

(defrule FORCE-TRANSMISSION: :ask-for-physical-principle-ef fectgeometry "" 
(declare (auto- focus TRUE) ) 

(special-function (input force) (function-verb channel) (output force) 
(attribute ATTRIBUTE) ) 

(solution-element (type ?) (exist FALSE)) 

?f <- (physical-principle (effect EFFECT) (ef fectgeometry NAME BOOL) ) 

=> 

(bind ?bool (ask-command "is_ef fective_geometry_a_straight_shaft" ) ) 
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Figure 15 Information Model for the Design Working Space and the Solution Elements 



(if (neq ?bool {}) then 
(if ?bool then 

(modify ?f (effect actio-reactio) (ef fectgeometry shaft TRUE) ) 
else 

(modify ?f (ef fectgeometry unknown FALSE) ) ) 
else 

(bind ?answer (yes-no-question "Is there effective geometry and is\ 
it a straight shaft?")) 

(switch ?answer 

(case TRUE then 

(modify ?f (effect actio-reactio) \ 

(ef fectgeometry shaft TRUE) ) ) 

(case FALSE then 

(modify ?f (ef fectgeometry unknown FALSE) ) ) 

(case QUIT then 

(assert (clear all)))))) 

Rule for the Evaluation of the Effective Geometry of a Physical Principle 

(defrule FORCE-TRANSMISSION: : ask- for-straight-shaft "" 

(declare (auto-focus TRUE) (salience 10)) 

(special-function (input force) (function-verb channel) (output force) 
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(attribute ATTRIBUTE) ) 

?f <- (solution-element (type TYPE) (exist TRUE)) 

=> 

(bind ?bool (ask-command " is_solution_element_a_straight_shaft " ) ) 

(if (neq ?bool {}) then 
(if ?bool then 

(modify ?f (type straight-shaft)) 
else 

(modify ?f (type not-straight-shaf t ) ) ) 
else 

(switch (yes-no-question "Is the geometry a straight shaft?") 

(case TRUE then 

(modify ?f (type straight-shaft))) 

(case FALSE then 

(modify ?f (type not-straight-shaft) ) ) 

(case QUIT then 

(assert (clear all)))))) 

Rule to Evaluate a straight shaft 

(defrule FORCE-TRANSMISSION: : ask-for-physical-principle-ef feet "" 

(declare (auto- focus TRUE) ) 

(special- function (input force) ( function- verb channel) (output force) 
(attribute ATTRIBUTE)) 

?f <- (physical-principle (effect EFFECT) (ef fectgeometry unknown FALSE) ) 
=> 

(bind ?answer (yes-no-question "Is the effect actio-reactio? " ) ) 

(switch ?answer 

(case TRUE then 

(modify ?f (effect actio-reactio) ) ) 

(case FALSE then 

(modify ?f (effect unknown) ) ) 

(case QUIT then 

(assert (clear all))))) 

Rule for the Evaluation of a Physical Principle 

(defrule FORCE-TRANSMISSION: : force-transmission-best-fulfilled "" 

(physical -magnitude (exist ?booll) (against ?bool2)\ 

(short-distance ?bool3)) 

(or (physical -principle (effect actio-reactio) \ 

(ef fectgeometry shaft TRUE)) 

(physical-principle (effect ?) (ef fectgeometry shaft TRUE) ) 
(physical-principle (effect actio-reactio) \ 

(ef fectgeometry unknown FALSE)) 

(physical -magnitude (exist TRUE) (against TRUE) \ 
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(short-distance TRUE) ) 

(solution-element (type straight-shaft) (exist TRUE) ) ) 

(not (designing-principle (type force-transmission) ( fulfilled TRUE) ) ) 

=> 

(if (eq ?booll ?bool2 ?bool3 TRUE) then 
(printing-out \ 

"Direct Force Transmission : Best Fulfilled With a Straight Shaft") 

else 

(printing-out "Direct Force Transmission : Fulfilled")) 

(assert (designing-principle (type force-transmission) ( fulfilled TRUE) )) ) 

(defrule FORCE-TRANSMISSION: : f orce-transmission-not-fulf illed "" 
(special-function (input force) \ 

(function-verb channel) (output force) (attribute ?)) 

(or (solution-element (type not-straight-shaf t) (exist TRUE) ) 

(physical -magnitude (exist TRUE) \ 

(against FALSE) (short-distance FALSE))) 

=> 

(printing-out "Direct Force Transmission: Not Fulfilled") 

(assert (clear all))) 

Rule for the Evaluation of the Quality of the Fulfillment of a force transmission 

(defrule FORCE-TRANSMISSION: : ask- for- traction-or-pressure "" 

(designing-principle (type force-transmission) ( fulfilled TRUE) ) 

=> 

(bind ?var (ask-command " is_shaf t_traction_or_pressure" ) ) 

(if (neq ?var {)) then 

(assert (shaf t-is-under ?var) ) 

( focus PRESSURE-AND-TRACTION-TRANSMISSION) 
else 

(bind ?answer (ask-a-question "Is the shaft under traction or pressure? "\ 
traction pressure quit)) 

(if (neq ?answer quit) then 

(assert (shaf t-is-under ?answer) ) 
else 

(assert (clear all))))) 

Rule for the Evaluation of technical traction or pressure 



7 EXAMPLE 

Given is an example depicted in Figure 16 . The effective geometry of the robot gripper is infolded by three design 
working spaces which have been placed user interactively. The designer can select one of them and specify what 
design principle he wants to have evaluated. 
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Design Working Space 




Infolded EHective Geomeiry of the Robot Gripper 



Figure 16 Result of Infolding the Effective Geometry in Design Working Spaces 



Figure Figure 17 shows the user interaction with the system. Because of not being able to derive the direction 
of the physical magnitude he is asked to enter their relative direction which is then instantiated into the product 
model. 



8 CONCLUSIONS AND FUTURE WORK 

We have modeled and verified the concept of decomposing an overall problem by design working spaces and 
evaluated the decomposed design by a knowledge based system in a small application on the DIICAD product 
model. Modeling design solutions in design working spaces and evaluating the decomposed solutions in a “scalable 
way” is possible. This is realized by using a knowledge based system which is integrated in the product model. 
The concept has been implemented on CLIPS, Pro/ENGINEER and itcl. 

Evaluating a design in an integrated product model in the described way is a promising approach. We consider 
it an important point that in the future basic research has to be done in developing methods for decomposition of 
design working spaces. So, our next steps will be to develop those methods to try to automate the decomposition 
process. 
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Figure 17 Example for the User Interaction with the Knowledge Based Sytem 
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Abstract 

In this paper we propose a method for innovation in design based on relaxing modeling 
assumptions. A design process is innovative if it can expand the design space it searches 
beyond the space defined by the initial problem formulation. Typically, an engineering 
design problem is formalized as a set of constraints that must be met on various proper- 
ties of the resulting design (e.g., weight), and an objective function on these properties to 
be optimized. The properties are defined by giving a set of equations for deriving them, 
and the parameters in these equations define the search space. However, these equations 
normally are simpHfied models of the general underlying physics, based on various assump- 
tions (e.g., radial symmetry) about the artifact being modeled. We present a method of 
expanding the initial design space, when it does not contain any acceptable designs, by 
introducing new parameters, based on a process of relaxing the assumptions underlying 
the given models of the physical properties. Our technique rationalizes the Dimensional 
Variable Expansion approach to innovative design found in the Hterature, and generalizes 
it. 



Keywords 

Design, innovation, modeling assumptions, search space, optimization 
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1 INTRODUCTION 

In order to solve an engineering design problem, it is often useful to formalize it, for 
instance to express it as a constrained optimization problem. Sometimes, however, it 
turns out that there is no acceptable solution to the problem as formalized. When this 
happens, a good human engineer can often find a modified formalization that opens up a 
larger space of designs, a space that is likely to include better solutions than the original 
space did, but is still constrained enough that it is feasible to find these better solutions. 

Mm R 





Figure 1 Innovation in Beam Design 

One common way to expand a design space is to move to a richer representation of 
the artifact being designed. For example, if the original formalization involved a uniform 
cylindrical beam, representable by radius, length, and material, we might expand the 
design space by allowing the beam to be a composite of two materials, as in Figure 1, 
thus adding two new parameters to our representation: the second material and the radius 
at which the material changes. When a design process extends our artifact representation 
this way, it is referred to as innovative design ([MZG89, CA91]). 

Can this kind of innovative design be automated? Yes - at least to the extent of propos- 
ing one or more larger spaces which the designer must then investigate for improved 
designs. A number of domain-specific heuristics have been used [ACP91, MA87], but the 
focus of this paper is on a domain-independent method developed by Cagan et al, called 
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Dimensional Variable Expansion* (DVE) [Cag91]. In this paper, we will present an analy- 
sis that rationalizes DVE as a process of relaxing modeling assumptions^ and we will show 
how this process can be extended to generate innovations beyond those that DVE can 
generate. 

In the next section we will summarize the DVE method. Following sections will describe 
our approach and show how it accounts for the innovations DVE can handle, and will 
illustrate how our approach goes beyond DVE. 



2 DVE 

DVE begins with a design task formalized as a constrained optimization problem: 

Minimize: /(x) 

Subject to: h(x) = 0 

g(x) < 0 



where x is a vector of variables, and h(x) and g(x) are vectors of functions. 

For instance, the beam design problem mentioned above might be formalized as in 
Figure 2. 

So far, this is a standard way of formalizing such engineering design problems. In 
addition, for DVE the variables must be tagged as belonging to one of several types, 
including the following: 

• A System variable represents a quantity that depends on the “characteristic size” 
[ACP92] of the artifact, such as weight. ^ 

• A Region variable represents a property of a region of the artifact, e.g. M and M' in 
the example in Figure 1, which is “not represented as an integral quantity.” [Cag91] 

• An Assignment variable represents a quantity that has contributions from a number 
of design regions. [ACP92] cites total mass as an example, but does not discuss why 
weight is a system variable but total mass is an assignment variable. 

• a Dimensional variable is a special kind of system variable that represents the physical 
dimensions of a device, e.g. the length and radius in the example above. 

*We will use this term to include the closely-related technique of Input Variable Expansion [ACP92]. 
t [Cag91] defines a system variable as one “defined ... as an integral quantity” over a region of the artifact, 
but apparently this statement is meant as a guide to the human preparing the tags, and the integral form 
is not given to their implementation of DVE. 
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Minimize W, subject to: 



where 
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( 4 ) 


W = irpLR^ 


( 5 ) 


p = k,(G) 


( 6 ) 


Ty = K^iG) 


( 7 ) 



and 

r is the shear stress at radius R 
Ty is the yield shear stress 
if is the angle of twist 
W is the weight of the beam 
T is the external torque 
G is the shear modulus 
p is the the density of the material 
L is the length of the beam 
R is the radius of the beam 

Ki and K 2 represent the relations between G and, respectively, p and r^, 

imposed by the fact that these three parameters are really all functions of the material. 

All that is known about K\ and K 2 is that they are monotonicly increasing. 



Figure 2 Formalization of Torsional Beam Problem 



Constraints are also tagged. Serial constraints are global (e.g. a constraint on total 
weight), and problem-specific update formulas for each must be given to DVE to tell it 
how to handle them. Parallel constraints are local to a region. 

Given the optimization problem and the tags, the DVE method first uses monotonicity 
analysis [CA91, PW79] to determine which constraints are active, i.e. are preventing 
further optimization of the objective function. Monotonicity analysis cannot, in general, 
completely determine which constraints will be active and which will not, but by imposing 
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some consistency conditions it can prune out many of the possible ways of partitioning 
the constraints into an active set and an inactive set. DVE then considers each of the 
remaining, consistent, sets of active constraints as a separate case, and handles the cases 
in turn. 

For a given case, variables which are involved both in active constraints and in the 
objective function are found and labeled critical This leads to the key innovation step: 
if a critical variable is also a dimensional variable, the artifact is divided into regions 
along that dimension. E.g., in the beam problem above, if radius were identified as a 
critical variable, DVE will propose dividing the beam into regions such that points with 
0 < r < i?i are in one region, points with Ri <r < are in another, etc. 

When a region is spht, region variables hke material are dupHcated, with a separate 
one for each region, thus leading to the new design above. DVE uses a number of trans- 
form;itions keyed off the variable and constraint tags to produce the complete new design 
problem, including the new optimization function and constraints. In our example, this 
process introduces the region variable M', the material in the inner region, along with 
R\ the radius of the inner region, as design variables, and thereby expands the space of 
designs to consider. 

If the same constraints are active in the new problem, DVE will further divide the 
artifact along this dimension, and eventually will inductively decide that the constraint 
will always be active, and jump to the Hmiting case where the region property (material 
in our example) varies continuously along the critical dimension (here, the radius). 

DVE is a powerful and general method. It has been shown capable of reinventing the 
I-beam and other innovations in a number of domains, including mechanical and chemi- 
cal engineering. Given the right problem formulation it is even capable of inventing the 
wheel[CA91]. 

However, the phrase “given the right problem formulation” points to the main problem 
of DVE. As [Cag91] notes (p. 81), “... domain knowledge is required to formulate the 
problem for use by the technique.^'’ [emphasis added]. Thus, for instance, in the same 
article on p. 82-83, the weight of a beam is represented by two variables, PV“***®” and 
The former is the total weight over all regions, the later the weight of each region. 
However, in the initial design, there is only one region, and thus It might 

appear that the reason for including W/*'* in the formulation is the expectation that after 
DVE has operated there will be multiple regions, and each will need a weight variable, so 
the single region in the initial state must have a weight variable distinct from the global 
total weight. 

How can the user know what tags to put on the variables without knowing in advance 
the innovation the system is supposed to come up with? E.g., why might we think of total 
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weight as a composite property, derived by adding the weights of a number of regions of 
the beam? Perhaps it is because we know in general that the weight of an object is the 
sum of the weights of its parts, or, equivalently (taking infinitesimal “parts”), the integral 
of its density over its volume. True, this knowledge in not present explicitly in the design 
problem as formalized, but in fact it is present implicitly. Equation (5) in Figure 2 is a 
very specialized equation for calculating weight, applicable only to cylinders of constant 
density; it can be seen as a consequence of the general knowledge that weight is the 
integral of density, and of the specific Eissumptions we are making about the shape of the 
beam. 

This insight leads us to view DVE as a special case of a more general process. The next 
section will describe this process and show how the innovation DVE does can be seen as 
a special case, and the following section will show how the approach extends DVE. 



3 INNOVATION BY RELAXING MODELING ASSUMPTIONS 

Our general process can be described, to a first approximation, as “use knowledge about 
modeling assumptions to guide the expansion of the design space.” In order to explain this, 
we first need to discuss modeling assumptions and how they are related to innovation. 
Then we will show how they can be used to guide the expansion of the design space. 
After that, we will give a more detailed description of our process by showing how it can 
duplicate DVE’s results on the torsional beam problem. 

3.1 Modeling Assumptions 

Generally, an engineering problem like the torsional beam problem above is not expressed 
in terms of abstract and uninterpreted variables. Rather, the constraints and the objective 
function are given in terms of physical properties about which an engineer has considerable 
knowledge, properties like weight and shear stress. 

Furthermore, the equations that relate these properties are specialized forms of more 
general physical relationships. E.g., Equation (5) in Figure 2 gives weight as a function of 
the beam’s radius, length, and density: 

W = itpLR^ 

which is a special case of the more general formula for weight: 



,a,r) dxdadr 



( 8 ) 
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and Equation (4) which gives the amount the end of the beam will twist is a special case 
of the more general formula: 

TL 

jT^GdA 

The specialized equations can be derived from the more general equations given a set 
of assumptions about the beam: 



• (Al) The beam is a cylinder with uniform radius R. 

• (A2) The material is uniform, and hence Ty and p are independent of position^ 



Constraints can also be specialized. As an example, we will look in more detail at how 
the constraint on r in our problem is derived. In general, the constraint would be 

Va, r, X t(q:, r, x) < Ty(a, r, x) 



I.e., the actual shear stress at each point must not exceed yield shear stress at that point. 
(Yield shear stress is the stress that will break the material.) Assumption A2 above allows 
Ty(a,r,x) to become just Ty. 

Given Assumption Al and a general model for r, we can infer that r is independent of 
a and x, and depends only on r, as follows: 




( 10 ) 



Furthermore, from this we can see that r(r) is largest at maximum r, i.e. for r = 72, so 
we can use the r = t{R) as an safe “overall” r. As long as this value does not exceed Ty, 
T will not exceed Ty anywhere. This gives us Equations 1 and 3 in Figure 2. 

Notice that without Assumption A2, the simplified constraint on r would be an over con- 
servative one. It is in general possible for t(R) < Ty(R) without requiring Vr t(R) < Ty(r), 
but since Ty is constant this cannot happen. It is the uniformity assumption that constrains 
the design more than is strictly necessary, by insisting that the material everywhere be 
strong enough to withstand the shear stress at the outer boundary. 

We refer to assumptions like Al and A2, used to derive a specialized or simpHfied model 
of a physical phenomenon, as modeling assumptions. 

When DVE expands a problem’s design space by introducing additional design parame- 
ters, it also must generalize the problem’s analysis models, that is, the equations modeUng 



^I.E., Ty and p are not functions of the coordinate variables a, r, and x 





108 



Part Two Methodologies for Knowledge Intensive CAD 



physical phenomena like weight, because the modeling assumptions inherent in the initial 
models are violated by some designs in the expanded space. For example, the density of 
the beam is no longer necessarily uniform. In other words, the design space in the original 
problem is restricted not only by the set of parameters used to represent the design, but 
also by the models of physics implicit in the equations. If we expand the parameter set, 
we may also have to “unspeciaJize” the models, i.e. return them at least part way to the 
general models they were derived from. 

3.2 Using Modeling Assumptions to Guide Innovation 

Given the discussion above, we can explain our key idea: rather than looking at the 
process of relaxing modehng assumptions and revising the models as a consequence of 
expanding the design space, suppose we look at it as a source of guidance for expanding 
the design space. That is, we will look at design innovation as a process of relaxing 
modeling assumptions. 

For instance, relaxing Assumption A2 above into 

• (A2’) The material and hence Ty and p are uniform across a, and a;, but change at 
some T. 

amounts to breaking the artifact into two subregions and allowing each subregion to have 
differing properties, as DVE does. 

A given assumption, however, can be relaxed in many ways. Why, for instance, do we 
assume in A2’ that material varies with r and not with a and/or 2 ? It turns out that we 
can get a lot of guidance from the equations for the objective and constraint functions, as 
we win see below. In the process of doing so, we will also show how innovation by relaxing 
modehng assumptions can create the same innovations as DVE. 

3.3 A Method for Innovation by Relaxing Assumptions 

The algorithm for design innovation by relaxing modehng assumptions is presented in 
Figure 3. Here we explain each step of the algorithm in detail in the context of the torsion 
beam problem formahzed in Figure 2. 

Optimal solutions for constrained optimization problems in the engineering domain are 
often located where some inequahties (such as ^(x) < 0, or ^(x) > 0) are active (i.e. 
satisfy equahty). In Step 1, one of the possible active sets is chosen. An active set consists 
of a subset of the inequahties (forced to satisfy equahty) plus the equahty constraints. 
The number of possible active sets is clearly exponential in the number of constraints. 
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Procedure Innovate 

Step 1. Apply monotonicity analysis ([Cag87]) to propose active sets 

and back substitute to simplify constraints and objective function. 
Step 2. For each active set: 

If the active set gives a feasible solution, output it. 

Otherwise, do Steps 3, 4, and 5. 

Step 3. Choose a set of assumptions to relax and 
a form to relax each such assumption. 

Step 4. Reconstruct the new set of constraints after 
assumption relaxation. 

Step 5. Redo monotonicity analysis and back substitution, 
and check each resulting new active set: 

- If it results in a solution, output it. 

- If it is not a solution but there has been improvement, 
go back to Step 3 and choose an additional relaxation 

If no active set is either a solution or an improvement, 
go back to step 3 and choose a different relaxation. 



Figure 3 Algorithm for Design Innovation by Assumption Relaxation 



However, monotonicity analysis ([Cag87, PW79]) is used to prune this space, just as it is 
used in DVE. Each active set corresponds to a subspace of the space of possible designs, 
and the designs in different subspaces generally have different characteristics. Every design 
that satisfies the constraints of our problem must be in one of these subspaces. 

In our torsion beam example, we apply monotonicity analysis and find that one active 
set which yields physically reasonable solution is: { 1, 3, • • •, 7 }. 

Since an active set potentially forces one or more inequality constraints to equality, 
we can exploit these new equations by back substitution into the constraint equations, 
and get more specific versions of the remaining constraints. We do back substitution and 
again check the monotonicity conditions, and new constraints are added to the active set 
if required to satisfy these conditions. After back substitution, numerical techniques (such 
as finite element methods) could be used if required (possibly, to approximate integrals 
numerically). 

In the torsion beam example, for the active set above, back substitution gives the fol- 



^For details of such an analysis involving monotonicity tables, see ([Cag 87 ]). 
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lowing expressions for the inactive constraints: 

W = ^m(G) and 

For each active set produced by Step 1, Step 2 checks if the non-active constraints are 
satisfied. If all non-active constraints are satisfied, we have a feasible solution which is 
optimally directed. ^ We output it, and backtrack to examine more active sets. Otherwise, 
we go to step 3. 

In our example, we will assume that the problem is such that there is no material (that 
is, no proper G), which would enable W to satisfy constraint (2. So, we go to Step 3. 

In Step 3, we propose assumptions to relax, and how to relax them. We assume the list 
of assumptions is known, perhaps having been recorded by the process that created the 
simplified models in the first place. When choosing assumptions to relax, priority is given 
to assumptions whose relaxation is known to improve the objective or lower the penalty 
associated with any unsatisfied constraint H (since we know this amounts to potential 
improvement of the design), followed by assumptions which affect the current active set, 
i.e. assumptions which mention variables in the active set. (We illustrate later on how 
the active set could be exploited usefully.) If several assumptions tie for the same priority 
explicit forms of relaxation suggested by the active set are preferred over forms used by 
default. Also, forms which de-simplify the model ** minimally are preferred. For example, 
if the active set suggests a particular explicit form for a function that would replace a 
constant function because of a.ssumption relaxation, we would prefer to use that form. 
Else, if the active set only suggests the variable(s) over which the function should vary, 
rather than an explicit form, we use a step-function over that(those) variable(s). If nothing 
is suggested by the active set, step-functions over different co-ordinate variables are tried 
in turn. 

While relaxing assumptions, we relax such that we de-simplify the model as little as 
possible, thus trying to capture simpler designs before more complex ones. This could be 
achieved in two ways. First, we can identify certain relaxations as less simpHfying than 
others. For example, while going from a constant function to the corresponding function 
that depends on several variables, we try functions with as few variables as possible. 
Thus while relaxing the homogeneity assumption we could go from constant density p to 



^In optimally directed design, as defined in [CA91] page 48, one is not guaranteed of optim£d solutions, 
but the search tries to eliminate suboptimal and dominated regions of search space while trying to improve 
the objective. 

1 1 The model generation process could store knowledge about qualitative effects of relaxing a model as- 
sumption it has introduced to simplify the model. 

**we return to this criterion at the end of this section 
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p(r,a,x). But, instead we would try p to be function of a single variable before trying 
two or all three variables. Secondly, the model generation process could create a partial 
order among groups of assumptions based on the degree of simpHfication achieved. Thus 
the model generation process could order gases in terms of decreasing simpHcity as ideal 
gases, Van der Waals gases and finally RedHch-Kwong gases. 

To see how Step 3 apphes to the example of the torsion beam, we first note that there 
are two assumptions: Al, the assumption that the beam is cyHndrical with uniform radius 
and A2. the assumption that the beam is homogeneous. Suppose nothing is known a priori 
about their influence on the objective or the penalty of the unsatisfied constraint. Both 
assumptions, however, affect the active set, and hence, both qualify for the same priority 
as candidates for relaxation. Now we see if any priority arises trying to predict forms of 
relaxation. Relaxing Al could yield other geometries but no particular one is suggested by 
the constraints in the active set. On the other hand, suppose we relax A2, the assumption 
of homogeneity. Recalling equation (10), and constraint (1) (from the active set) we get, 
< Ty. Under assumption A2, this was speciahzed to yield < Ty. If A2 is relaxed 
and this inequality is to be active, it immediately shows, Ty = that is, Ty is a function 
of r. (There is no guarantee that after relaxing A2 this constraint stays active, but the 
fact that the constraint Vr, < Ty{r) could be satisfied even when Ty(r) < t(R) for 
r < R, could result in an improvement of the objective or some penalty.) Since choice of 
Ty fixes the choice of the material, G and p gets fixed too - and hence, are functions of r. 
We then have, (recaUing equation (9)) 



TG(r)r 
27t / G[r)r^dr 



( 11 ) 



In this case, the expHcit form of the function Ty after relaxation is unknown, since the 
exphcit form of G(r) is unknown. In the absence of exphcit forms of functions, step 
functions are used to replace constant functions. DVE essentially does the same - it too 
proposes step functions to iteratively replace constant functions and seeks to improve the 
objective, gaining extra degrees of freedom from the newly introduced step parameters. 
Thus in this case the function for Ty(r) is. 



Tyi for 0 < r < 

Ty 2 for R\ <T < R 2 



(12) 



Similar step functions are proposed for G, p etc. 

In Step 4 we reconstruct the new set of constraints and relations after relaxing the 
assumption set suggested in Step 3. In the torsion beam example, we thus relax the 
assumption set {A2}. The reformulation is shown in Figure (4). 
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Minimize W = Wi -\-W 2 , subject to: 



where 



Gi > 0, 


G 2 ^ 0 


(13) 


IV 

0 


> 0 


(14) 


VI 


T2 < Ty2 


(15) 


W<Wo 




(16) 


92 < 9m<ix 




(17) 


= irp^LRl, 


W 2 = ■KP2L(R^ - Rl) 


(18) 


Ti = 


G292^2 

L 


(19) 


= (^2 




(20) 


¥>1 = 


2 T 2 L 

~ 2lG2{Ri - Ri) 


(21) 


R 2 — Ri — t 




(22) 


Ti+Ti = T 




(23) 


Pi = A-i(Gi), 


p2 = Ki(G2) 


(24) 


Tyl = K2(G2), 


Ty2 = K2(G2) 


(25) 



Figure 4 Torsional Beam Problem After Relaxation of Assumption 



In step 5, we redo the monotonicity analysis, and try each of the resulting active sets to 
see if it is a solution to the problem, or if it at least looks hke a promising step towards a 
solution, i.e., if either (i) the objective has improved (that is, it decreased for a minimiza- 
tion problem, or it increased for a maximization problem) from the previous formulation 
or (ii) the penalty of some inactive inequality has decreased from the previous formula- 
tion. (The penalty associated with an inequality constraint is defined as max(0^g(x)) for 
g(x) < 0 and as abs(min(Oyg(x))) for ^(x) > 0. Essentially, it measures the ’badness’ of 
a violated inequality constraint.) 

If an active set is a solution, we output it and go on to the next active set. If an active 
set looks promising, we go back recursively to Step 3 and try adding a further relaxation to 
the current one. If none of the active sets is either a solution or even promising, backtrack 
to Step 3 and try a different relaxation. 

In our example, after monotonicity analysis one 'active set that is physically relevant 
includes (among other constraints) > 0 and T 2 < Ty 2 , but not G 2 > 0 and Ti < Tyi. This 
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implies pi = 0 and p 2 > 0 (from 24), and we get a hollow tube. Using back substitution 
(Step 2), from (18), (24), (22) and Gi = 0 we get the new objective as: 

W = 7rLKi(G2)ti2R2 - t) (26) 

The new objective is an improvement (over the one before relaxing the assumption) so 
long as: 

K,(G2)t(2R, -t)< K,(G) (27) 

Now from = KiiGi), tj = and iZj - f?i = t we get 

(using back substitution): 

2T 

+ (4t^ - )Ri-t* = 0 (28) 

7rA2((-r2j 

Since, equation (28) decreases one degree of freedom, any two of i? 2 , G 2 and t can be 
varied to satisfy Equation (27) and hence improve the objective over the old one. The 
initially unsatisfied constraint (2) can now be satisfied. In a similar way, when Gi > 0 
and G 2 > 0 are both inactive, it can be shown that the step functions proposed devise a 
composite rod with an improved objective. 



4 ADVANTAGES OF ASSUMPTION RELAXATION 

The previous section shows how a typical innovation derived by DVE can also be derived 
by relaxing modeUng assumptions. 

DVE can be viewed as a special case of the general principle of assumption relaxation. 
As a result of relaxing assumptions one introduces more design variables into the problem 
formulation (in particular, for DVE, these are the step-parameters), thereby extending 
the search space. In this section we illustrate how the general principle improves over 
DVE in at least two ways. 

4.1 Direct Suggestion of Solutions in the Limit 

We consider the role of the active set of constraints in suggesting relaxations. We show 
that by considering these, we can arrive at the same designs which DVE achieves as the 
limit of several of its iterations by inducing a trend over those iterations. Our approach is 
more direct, and since it avoids the DVE iterations whenever possible, achieves the same 
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Minimize W, subject to: 



where 



(T<(Ty 


(29) 


T<Ty 


(30) 


W<Wo 


(31) 


G>0 


(32) 


R>0 


(33) 




(34) 




(35) 


W = %pLR? 


(36) 


P = K^{G) 


(37) 


Ty = K 2 (G) 


(38) 


Cy = Kz(G) 


(39) 



and 

P is the transverse load 
a is the bending stress at distance x 
(Ty is the bending stress at yield 

and, the other parameters correspond to those in Figure 1 



Figure 5 The Problem of Beam Under Bending Load 



results faster. We illustrate this by considering a variation (Figure 5) of the example 
considered earlier. A beam, of length L having minimum weight is to be designed, such 
that it is clamped at one end and subject to a transverse load P at the other end. 

Assumptions (Al) and (A2) both carry over from the previous example. Consider the 
case where bending stress is dominant. This corresponds to the active set { 29, 34, • • •, 
39 }, and leads to 

VK,(G)} 



(40) 
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/ APL 

Suppose, given P and L, no choice of material (that is, no proper G), enables W to satisfy 
constraint (31). We seek hints from the active set to see if some assumptions could be 
relaxed usefully. 

The active set impHes 

APx 

Based on this we could relax either of the assumptions. Relaxing only (Al) (but not A2), 
leads to as a function of x: 




so long as, constraint (29) remains active (that is bending is dominant). But supposing 
that constraint (30) is active instead of constraint (29) (that is, shear stress is dominant, 
rather than bending stress), the radius is given by 




One should note at this point that it is quite possible for different active sets to dictate 
solutions over different regions over the artifact (just hke it is possible to have the same 
active set dictate the solution over the whole artifact.) One should simply explore all such 
possibihties to generate solutions, and finally keep only the ones physically relevant. The 
interesting solution in this example has different active sets dominating different regions 
over the co-ordinate variable x. The point of crossover^^ is found by equating these two 
expressions for R, giving = ^ (;—) • Thus, for x < Xc (that is, for regions nearer 

to free end) shear stress dominates and the radius is given by equation (44); whereas, 
for X > Xc (that is, for regions nearer to the clamped end) bending stress dominates and 
equation (43) gives the corresponding R. Since the new R is a strict underestimate of the 
previous R given by equation (40), the new W will also be lower than before. 

It should be noted that this is exactly the solution proposed after several iterations of 
DVE followed by an ’inductive leap’. The design proposed by such an inductive leap needs 
to be validated, since it is not guaranteed to be correct. Our method proposes exactly the 
same solution, and just like DVE, needs to be vaHdated. But in proposing the solution 



(42) 



It where the active set changes. 
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we avoid the several iterations of DVE. This is significant because of the way in which 
active sets are chosen. Given m constraints there are 2”^ ways of choosing active sets. 
Monotonicity analysis prunes this space, and reduces the choice to a lower number. But 
higher the number of equations, higher the number of choices. In each iteration of DVE, 
(n — l)up additional constraints are added, where n is the number of regions to which 
a single region expands and Up is the number of parallel constraints in a region before 
the expansion. So after several iterations of DVE, the process becomes computationally 
expensive. As acknowledged in ([CA91]), some constraints do not dominate for severed 
iterations, and induction by DVE based on too few iterations would wrongly predict 
those constraints to be inactive. That is why in DVE, even though certain constraints 
are deemed inductively active, all constraints need to be considered across the continuum 
of induced trend to check for constraint violations. Our heuristic of relaxing assumptions 
based on suggestions from the active set can reduce several iterations of DVE, and hence 
is computationally more attractive. 

What if we relaxed assumption (A2) instead of assumption (Al) ? Going back to equa- 
tion (42) (under bending dominance) we find that relaxation of assumption A2 suggests 
(Ty to be a function of x according to the right hand side of that equation. For the 
region before the crossover point, that is, for x < Xc, shear stress is dominant, and hence 
the density pi is determined by Ty = For the region beyond the crossover point, 
bending stress dominates and p gets chosen (via Oy) according to equation (42). Following 
equation (8) the objective is now given by 

W = 'kP?XcP\ -f I p{x)dx (45) 

Jxc 



For the region where bending stress is active, <Ty{x) is a strict underestimate over its old 
counterpart <Ty, and since Oy and p are monotonically related because of equations (37) 
and (39), it follows that the new p[x) would underestimate the old p. The contribution 
to the objective by the region a; > Xc (as given by the second term on the right hand side 
of equation 45) would be strictly less than earher, and hence there is a good chance that 
the objective decreases as weU. 



++ numerical techniques could be employed to evaluate the integral involved since p(x) might not be known 
in closed form or could be too complicated 

§§ There is only 1 degree of freedom between density p, yield shear stress Ty and yield bending stress <7y, 
since choice of any one effectively fixes choice of the material. 
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4.2 Importing Implicit Variables 

In this section we show how our approach is more general compared to DVE. We present an 
example where relaxing model assumptions leads to introduction of variables in the search 
space which is not possible by DVE. DVE essentially dupHcates variables (dimensional, 
system and region variables) over the regions it expands to. What if no expHcit variables 
remain (to get duplicated) because of model simplification? DVE can’t regenerate them. 
The intuition is that because of model simplification some design variables may have 
gotten lost which are not related to dimensional variables (or more fundamentally, co- 
ordinate variables) in any way in the de-simplified model we get after relaxation^ and 
DVE can’t handle such cases. 

Consider the following design problem. You are given a spring (of spring modulus A; > 0) 
attached to a fixed support at one end, with a mass m at the other end. The mass moves 
along a single dimension, under an external force F on it. F = ki k 2 sin(ut), where 
t is time and ki,k 2 are constants greater than 0. The objective is to minimize mass m 
subject to the constraints: (i) the mass m is below a threshold, (ii)after a long time, the 
amphtude a does not grow beyond a given threshold Qq, and (iii) w is not lower than the 
natural frequency ujn by more than a very small fixed threshold 8. 

The problem is formally stated below. Minimize the mass m subject to the constraints 

C: 



TThdSS • 7Tl ^^^0 



(46) 



amplitude \ a < ao 



frequency : 0 < ljn — c*; < 5 



The displacement at time t is the superposition of Xg and Xp given by: 

kiCos{uNt) uk2sin[wNt) 
k UNk(l — 



and 

Xp = 



k2sin(u;t) 





(47) 

(48) 



(49) 



(50) 



these are respectively the general and particular solutions of the governing differential equation: 
+ kxz=F 
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where, 



natural frequency : = 



(51) 



When qjn — < S is active, it follows from equations (49) and (50) that since 8 is 

a small quantity, the magnitude of both Xg and ip, and hence the ampHtude, is large. 
In fact the fixed quantity 8 could be so small that the amplitude is sufficiently large to 
violate constraint (47). 

We seek to lower the penalty associated with the violated constraint (47). We relax the 
original assumption of no damping since the model generation process could note that 
such a relaxation would reduce the amplitude (and hence the penalty associated with 
the violated constraint (47)). Note that, in this case, the active constraint does not by 
itself involve any assumptions. In case the model generation process did not produce the 
annotation of the effect of relaxing this assumption, we would anyway relax the assumption 
and see the consequence in the next iteration. 

We thus relax this assumption of no damping, and add to the model: 

dx 

Damping force : Fd = —kD-r~ ( 52 ) 

dt 

where ko > 0 is the damping parameter. 

The displacement for large t, is now : 

Xp = ^ Acos(ujt — <l>) (53) 

where. 




(54) 



Assuming — u < 8 is active, even though we stiU have a difference of only 8 between 
ujn and a;, the amplitude A in equation (54) can be reduced by suitably choosing kD- Thus 
it follows that the newly introduced variable ko lets us reduce the penalty associated with 
the violated constraint (47) to zero and allows a feasible design. 

We have shown earlier that DVE is essentially the result of relaxing certain types of 
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simplifying assumptions about the model. Expansion of a dimensional variable is tanta- 
mount to allowing variation of properties over one or more co-ordinate variable which 
was not allowed in the earUer model. But what about non-dimensional variables lost due 
to simphfying assumptions? For example, in the case of the oscillator, the simpHfying 
assumption of no damping results in no trace of kj) in the model; by relaxing that as- 
sumption we can introduce it and expand our search space to generate new designs, not 
possible in the earher model. This is clearly not possible in DVE. 

We should note here, that our design task consists of assigning values to design param- 
eters. How they are actually reaHzed is another issue. Thus we can think of a different 
mechanism (maybe human assisted) which knows how to actually compose the design 
given these design parameters. Thus given radius, length and the material the ’composer’ 
knows how to put together the cyhnder. When a damping parameter is introduced, the 
’composer’ is expected to know how to achieve this damping (maybe introducing friction 
etc.). The actual working of such an operation is beyond the scope of the current work. 



5 RELATION TO OTHER WORK 

Aside from the work on Dimensional Vzuiable Expansion, there are several other pieces 
of work that are related to the ideas reported here. 

PROMPT ([MA87]) stores large amount of physics knowledge in its Graph of Models 
structure (described in more detail in ([ACP91]). Each node represents a model of the 
system being analyzed and the edges represent the differing approximations between two 
nodes. Search switches between nodes in the graph when prediction of a model fails to 
meet observations. PROMPT uses the interesting idea of a case hbrary of precompiled 
heuristics, known as modification operators , to modify a prototype. Example of such an 
operator would be one for redistributing mass from areas of low stress to areas of high 
stress, plus some applicability conditions for such an operator. While use of precompiled 
human experience imparts better design capabilities and leads to efficiency, by the same 
token, modifications not specified by heuristics cannot take place. Functional relationships 
between parameters are not utilized. Furthermore, the system does not reason with in- 
equahty constraints to optimize the design. Our method resembles this work in essentially 
creating various models based on differences of modeling assumptions and searching in 
different models; but, there are differences with our approach. For one, the representa- 
tion for models differ in granularity - our’s is more fine grained. We do not use human 
compiled heuristics, and hence our method does not suffer from the resulting drawback 
mentioned above. We do utilize functional relationships between parameters and we also 




120 



Part Two Methodologies for Knowledge Intensive CAD 



reason with inequality constraints to push the design towards optimality. Given the task 
of beam design under torsional load, DVE designs the composite beam, but PROMPT 
cannot achieve it. Our method achieves the same design as DVE does in this task. 

[FF91] describe a method for model composition. They compose a model sufficient to 
answer a query while minimizing extraneous detail from a general domain theory and a 
structural description of a specific system. They decompose a domain theory into a set 
of model fragments and deduce a set of assumptions from the requirements of the query. 
Then they use an ATMS to find a minimum set of model fragments sufficient to satisfy 
the query. This work ([FF91]) is closely related to [ACP91] and it relates to our work in 
that we too try to find the simplest model that allows us to design the artifact. Their task 
at hand is, however, different from ours: they take the structural description of a system 
and compose a model to satisfy the query; we, seek to design the structure such that it 
behaves in a particular way. Our approach also differs in the way solutions are searched. 
We search in a simplified model first, and if we hit an impasse in that model, we relax 
some assumptions and go to a more complex model. Their approach is to synthesize a 
minimal but sufficient model. 

[Wel92] presents a framework for dynamically changing model accuracy based on model 
sensitivity analysis. Their goal is to mechanize the process of crafting underlying models 
of complex physical systems by building a model management system that evaluates 
simpHfying assumptions and selects appropriate perspectives. Our work is a step in the 
same direction in the sense that it shows when and how to relax simpHfying assumptions 
opportunistically to come up with innovative designs. 

[LSJ92] and [LS90] describe a system called MSG, which generates mathematical models 
to analyze physical systems involved in heat transfer behavior. It uses strong domain 
theory to guide model construction. It first identifies regions of interest on an object, then 
determines relevant heat transfer and energy storage processes and finally transforms these 
processes into equations. A set of choices for the models in terms of control volumes, and 
heat flows are to be made and a related paper ([LS93]) describes reduction operators used 
to make these choices. Various rough models are used to estimate the physical parameters 
on which these rules depend. The connection of this work with our work is in the fact that 
both recognize the need for modeHng underlying physics at various levels of approximation. 
While MSG uses model simpHfication to guide model generation, our approach exploits 
the assumptions recorded by such a process to guide design innovation. Both approaches 
underscore the importance of models of varying levels of simpHcity. 
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6 CONCLUSION 

We have proposed a method for innovation in design based on relaxing modeling assump- 
tions. Engineering design problems are generally formalized as constrained optimization 
problems where the objective function and the constraints refer to several properties of 
the resulting design. While setting up such a problem, sever 2 d assumptions about the 
model are made to narrowly define the problem context. Our key observation is that such 
a process could import assumptions that constrain the problem too much to find a feasible 
solution. By relaxing appropriate modeling assumptions we can modify the search space 
profitably. We have shown that the method of DVE, found in the Hterature, is a special 
case of this. We have also shown that in some of the cases where DVE proposes a solution 
by induction, our method proposes the same solution with less computational effort. We 
have also shown that our method generalizes DVE to include design innovations based on 
reimporting (non-dimensional) variables lost originally due to model simpHfication. We 
observe that the model generation process could enhance the power of this method by 
introducing assumptions incrementally and storing information as to how the assumptions 
influence the design. 
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Abstract 

During early stages of the design process, functional descriptions are often used to describe the design 
object behavior. Based on the knowledge of such functional descriptions of the design object (i.e. the 
design parameters contained in these functional relationships), the Pi-theorem is used to derive the 
associated dimensionless groups. These dimensionless groups are shown to fulfill the necessary conditions 
commonly expected of evaluation parameters. Based on the validity of the consequently established 
evaluation hypothesis that “any minimal description in the sense of the Pi-theorem is an evaluation”, 
these automatically generated dimensionless groups then serve as evaluation parameters for the purpose 
of design object evaluation. 

The properties of this evaluation method, such as minimality, completeness, hierarchical decomposition, 
consistency, causality and sensitivity analysis of the design variables, are derived and discussed. A brief 
example of the conceptual design of a gas turbine shows the feasibility of the suggested approach. This 
design evaluation method should in principle be common to the reasoning process of the engineer since 
it relies on the traditional engineering technique of dimensional analysis. 

Keywords 

Design evaluation, evaluation hypothesis, functional modeling, dimensional analysis, Pi-theorem. 



1 INTRODUCTION 

Functional modeling means the description of the design object in functional terms. The functional 
structure of the design object can hereby be described using several functions and their interfaces or flows, 
see Kuttig (1993). These functions are generally defined as relationships between the input variables, the 
output variables and the state variables of a system, see GuideUnes VDI 2221 (1987). While verbs and 
nouns are often used for the description of a function and abstract symbols are used for the visualization 
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of a function, see Pahl and Beitz (1993), the term ‘functional modeling’ in this paper is restricted to 
the description of design objects by functional relationships /(xi, , . . ,a;„) = 0 of the physical design 
parameters xi, . . . , x„, such as lengths. Young’s modulus or masses. 

In all stages of the design process, the design decisions are commonly based on these real design 
parameters xi, . . . , Xn- However, it is shown in this work that these real dimensional quantities do not in 
general satisfy the necessary conditions for evaluation parameters. It is argued that there exists a strong 
epistemological reason that only the dimensionless groups derived from these dimensional quantities 
Xi fulfill the necessary conditions of evaluation parameters. 

From design experience, it is also known that there are several levels of difficulty and complexity 
associated with functional modeling based on design parameters: 

• Firstly, the so-called relevance list xi , . . . , x„ of the design parameters involved in the description of 
the design object function /(xi, . . . , Xn) = 0 needs to be established. This relevance list may, however, 
change during the design process, e.g. when further knowledge is obtained. 

• Secondly, the functional relationship /(xi , . . . , x„) =0 relating the design parameters is often unknown 
or may change during the design process, e.g. when other solution principles are selected. 

The method of dimensional analysis has recently been shown to be able to handle these difficulties, 
see Rudolph (1995a), since the formalism of dimensional analysis based on the Pi-theorem requires only 
qualitative information about the relevance list of the physical design parameters Xi , . . . , x„ and is ideally 
suited for processing qualitative physical knowledge encoded in the functional descriptions of the design 
object. Dimensional analysis has therefore already been applied to engineering design problems in the 
past, see Dolinskii (1990) and Kloberdanz (1991), where it was used to aid the modeling and helped to 
gain a deeper understanding of the functional behavior of the design object. In other works dimensional 
andysis was used as a basis for the technique of qualitative reasoning, see Bhaskar and Nigam (1990). 
However, these works will not be addressed here any further, since they are the topic of ongoing research, 
see Rudolph (1995b). 

In this work, the notation of dimensional analysis is shown to solve the design evaluation problem, 
which frequently occurs during design synthesis when choosing among various design alternatives. Section 
2 presents the epistemological foundation of the evaluation problem. Section 3 presents the theoretical 
foundation of the suggested evaluation model. A short application example demonstrating the use of 
the suggested evaluation method is presented in section 4. Section 5 closes with a discussion and the 
conclusions drawn from this work. 

1.1 Evaluation problem 

The overall evaluation of a design object commonly consists of various different partial evaluation aspects, 
also called evaluation criteria. If one accepts the principle of decomposition of a main criterion (or goal) 
into several smaller sub-criteria (or subgoals) and thus the aggregation of evaluation components into a 
global evaluation, respectively, then any evaluation model based on such an assumption can only be a 
valuable tool for the evaluation of design objects during the design process if at least acceptable 2 inswers 
can be found to the following central questions, see Rudolph (1995a): 

• How to structure the used goal criteria hierarchy ? 

• How to determine the evaluation of various distinct goal criteria? 

• How to aggregate multiple goal criteria into one single goal criterion ? 
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mapping 




Figure 1 Description, mappings and evaluation 



Due to the lack of a formal methodology providing answers to these fundamental questions until now, most 
classical evaluation models (also called decision making models) require these questions to be answered 
by a human decision maker, see Hwang and Yoon (1981). The task of the human decision maker is to 
establish the description graph of the design object, to determine the evaluation graph and then find the 
corresponding mapping of the description onto the evaluation. This is shown in fig. 1. The infiuence of 
the decision maker leads to the central question of to what extent a decision refiects the personal beliefs 
of the decision maker or whether an objective evaluation should be the unique property of the design 
object. This is the key idea underlying this work and this issue will be investigated in more detail in the 
following section. 



2 MOTIVATION 

From a comparative analysis of some existing decision theories and evaluation models in Rudolph (1995a), 
it can be concluded from epistemological reasoning that 

• under the assumption that an objective evaluation exists in general, it may not depend on the arbi- 
trarily chosen definitions of physical units and therefore has to be dimensionless, 

• a reproducible and objective evaluation can only exist if it is based on a description derived from some 
type of law which has to be dimensionally homogeneous, 

• an evaluation method should turn into exact physics and be consistent in the case of complete knowl- 
edge about a design object. 

If the emphasized epistemological requirements mentioned above are considered as necessary conditions of 
a description in the appropriate implicit mathematical form of a functional relationship f(x\, . . . ,Xn) =0 
of physical variables, it can be shown that a universal method exists for constructing such dimensionless 
quantities from dimensionally homogeneous function equations by means of the Pi-theorem. This will be 
presented in greater detail in the next section. 

To ease the understanding of the introduced model, the following terminology will from now on be 
used as shown in fig. 2, which is essentially the same diagram as fig. 1. In fig. 2, X{ and X represent the 
description, while ttj and II represent the corresponding evaluation. The mapping is represented by (po 
and (fj, while </?i and (^3 are the respective aggregation functions. 

The whole concept of functional modeling is linked to this approach by the fact that (fi is the function 
/ relating the physical design parameters xi, . . . ,x„. Correspondingly, <^3 is the function F aggregating 
the partial evaluations nj into a global evaluation. As will be shown later, neither ipi nor (pz needs to 
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Figure 2 Description, mappings and evaluation 



be known explicitly. On the contrary, the knowledge of the dimensional information of the relevance list 
xi,...,Xn of the physical design parameters is sufficient, as shown in the theoretical derivation and the 
example of the gas turbine. This knowledge is generally available through engineering experience. 



3 FOUNDATION 

The advantageous exploitation of the dimensional analysis in the establishment of a design evaluation 
model will be shown in the following. In order to do so, the so called Buckingham- or Pi-theorem, see 
Buckingham (1914) and Bridgman (1922), derived from the theory of dimensionally homogeneous function 
equations, is shown. 

Pi-theorem, Bridgman (1922). From the existence of a dimensionally homogeneous and complete equa- 
tion f of n physical quantities X{ the existence of an equation F of only m dimensionless quantities ttj 
can he shown 

f(Xi,...,Xn) = 0 

F(7ri,...,7T„j) = 0 (1) 

where r = n — m is the rank of the dimensional matrix constructed by the X{ and with dimensionless 
quantities itj of the form 



Ttj = (2) 

i=l 

with j = 1 , . . . ,me W and the ajiClR as constants. (The definition of the dimensional matrix is given in 
fig. 3 and examples are given in the application section). 

The so-called dimensional matrix in the left hand side of fig. 3 has n rows for the design parameters Xi 
and up to A; < 7 columns for the dimensional representation of the parameters expressed in the base units 
of the employed unit system (A; < 7 is today generally valid in physics, since currently 7 independent 
physical dimensions, mi = mass, m 2 = length, m 3 = time, m 4 = temperature, ms = current, me = 
amount of substance and mr = light intensity in form of the known 7 Sl-units [kg], [m], [s], [K], [A], [mol] 
and [cd], can be distinguished). 
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mi m2 rrij. 




Figure 3 Definition of Dimensional Matrix Computations 



To calculate the dimensionless products in equation (2), the dimensional matrix of the design param- 
eters xi,...,Xn as shown on the left hand side of fig. 3 needs to be created. Multiples of matrix columns 
may then be added to each other to obtain the upper diagonal form of the dimensional matrix as shown 
on the right hand side of fig. 3. These matrix operations are rank preserving operations in the sense of the 
linear algebra and therefore lead to a modified dimensional representation of the design variables X{ in the 
original dimensional system mi , . . . , m* in a new, equivalent dimensional system mi , . . . , m^, with r <k. 
The exponents aji of the dimensionless products in equation (2) are then automatically determined by 
the values of the coefficients aji in the hatched part of the matrix on the lower right hand side of fig. 3. 
As a consequence of these rank preserving operations on the dimensional matrix, the subset of the design 
parameters xi,...,Xr must be selected from the whole set of design parameters Xi , . . . , x„ in such a way 
that their transformed dimensional representation in the transformed dimensional system results in a 
diagonal form. This simple procedure is illustrated in the derivation of the dimensionless products of the 
gas turbine example. 

The evaluation hypothesis presented below is used to derive the properties of the evaluation model and 
can be proved with the help of the Pi- theorem. An evaluation represents a qualitative and quantitative 
measure of an object or process. As long as its representation form is still redundant, this redundancy 
can be eliminated without loss of information. Therefore, any evaluation must possess the property of a 
redundancy-firee representation form and has to be minimal in this respect, see Rudolph (1995a). This 
means that the number of independent evaluation parameters cannot be reduced any further. Since the 
Pi-theorem exhibits all the required mathematical properties of evaluation parameters, the evaluation 
hypothesis that “any minimal description in the sense of the Pi-theorem is an evaluation” is postulated. 

The application of this evaluation hypothesis as the key idea of the evaluation model is simple. Let 
/(xi, . . . ,a;„) = 0 be an arbitrary functional description of the design object, then F(7 Ti, . . .,7Tm) = 0 
represents the corresponding evaluation. The individual ttj represent the individual nodes of the evaluation 
graph in fig. 1, while F represents the aggregation function. 

In order to clarify and separate the use of the terms “description parameter” from the term “evaluation 
parameter” in this paper, it is stressed that a description parameter is considered as a (physical) variable 
Xi possessing a dimensional representation (in the form of the 7 Sl-units length in [m], mass in [kg], and so 
on, or combinations of the seven). Thus, there exists a one-to-one relationship between the design object 
in reality and its chosen representation form in the form of the design parameters Xi. The evaluation 
parameters, however, are the dimensionless groups tTj , which are monomials of the design parameters and 
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are therefore a many-to-one relationship between the design object description and its chosen evaluation 
form in the form of the evaluation parameters. More properties of the evaluation model are presented in 
the following section. 



4 EVALUATION MODEL 



Using the proof of the Pi-Theorem, the following list of selected properties can be shown for the evaluation 
method, see Rudolph (1995a); 



• Evaluation. The problem of evaluation can be reduced to a problem of description. The problem of 
evaluation is solved exactly in those cases where a complete description exists. 

• Minimality. The dimensionless products form a basis in the sense of a linear vector space. The property 
of a vector space basis such as minimality is therefore also valid for so-called fundamental systems of 
dimensionless products. 

• Granularity. Adding one more design parameter a;„+i to the original description set of , . . . , gen- 
erally adds one more tt^+i and leaves the original set of evaluation components tti, . . . , unchanged. 
This property supports the procedure of hierarchical refinement in the sequence of steps of the design 
process. 

• Hierarchy. Solving F for a specific tTj immediately creates a consistent hierarchy as shown in fig. 2. 
This property can be extended to multiple hierarchies. 

• Sensitivity. The differential formulation of the model laws with ttj = const is diTj = 0. Differentiating 
equation (2) lezwis to 



dTTj 




j = 



( 3 ) 



and setting dwj =0 leads to the general form of an iso-line of an evaluation component. If only 
infinitesimal changes of two design parameters Xj and X{ are permitted, with all other changes equal 
to zero, one obtains 



^^3 _ -■ ^3 

dxi Xi 



i = 1, . . . ,r 



( 4 ) 



which is analogous to the expression derived in Bhaskar and Nigam (1990) for the purpose of ’’quali- 
tative reasoning”. 



A few ideas on how the evaluation method can be tested is given by the fulfillment of the following 

selected epistemological thoughts, see Rudolph (1995a): 

• Causality. The evaluation II is determined by the complete description X in the mathematical sense 
as a necessary and sufficient condition. 

• Invariance. The evaluation II is invariant under scale transformations of the physical units employed 
in the description X of the design object or process. 

• Abstraction. Since the same evaluation II is the property of a whole class of similar but well distinct 
design objects in X, the mapping from X to II is mathematically surjective and not injective. 
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Figure 4 Block Scheme Gas Turbine 
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• Consistency. Since the evaluation is generated by a mapping, the consistency over multiple hierarchy 
levels is guaranteed if the theory underlying the design description hierarchy is consistent. 

The application of the evaluation method is demonstrated in the next section using the example of 
the conceptual design of a gas turbine. This example has been chosen because of the fact that analyt- 
ical solutions are known, thus the outcome of the purely formal dimensional analysis procedure can be 
compared to this known solution. 

4.1 Gas Turbine Evaluation 

The conceptual design evaluation of a gas turbine based on the functional description of the design 
parameters is shown. The functional description of the gas turbine is therefore supposed as given, but 
can be found in most reference books on thermodynamic modeling, such as in FVohn (1977). In a first step, 
the description of the gas turbine consists of the block scheme in fig. 4. In this way, only those dimensional 
thermodynamic quantities which cross the system limits need to be considered, see FVohn (1977). These 
are the thermal power Qb, chemically supplied in the form of fuel, which is transformed into the (shaft) 
power Wn and into (heat) power Qa- The functional modeling of the gas turbine has in this first step 
the form g(QB,WN,QA) = 0. The resulting dimensional matrix G in table 1 with n = 3 has the rank 
r = 1. From the rank preserving operations described in fig. 3, the two following dimensionless products 
7TG1 and 71(52 are determined according to equation (2) to be equal to 

7TG1 = Wn/Qb (5) 

7TG2 = QaIQb (6) 

Prom thermodynamic considerations, it follows that Qb is partly transformed into Wn and is partly 
released as Qa, resulting in the energy conservation equation Qb = -Wn - Qa, assuming a system- 
egotistical position is adopted. Thus, G ( 1 ^ 01 , 1 ^ 02 ) — 0 can be directly determined. However, without this 
theoretical knowledge, experimental measurements of Wn and Qb are sufficient to obtain the numeri- 
cal values of the evaluation ttgi of the gas turbine efficiency as well and are conform with the classical 
theoretical findings. Once the the dimensionless product ttgi for the evaluation of the power tramsfor- 
mation efficiency is obtained, the one-step evaluation hierarchy shown in fig. 5 can be used to represent 
the current gas turbine evaluation. Additionally, this way of evaluating the gas turbine efficiency using 
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Figure 5 One-step Evaluation Hierarchy 




Figure 6 Component Scheme of Gas Turbine 



G(7Tgi, 7rG2) = 0 is consistent with the traditional definition of the thermal efficiency coefficient r]th^ which 
is defined as 



-Wn 


Qa 

= 1 + ^ 


( 7 ) 


Qb 


Qb 


-7TG1 


= 1 + 7TG2 


(8) 



Refinement. In the next step of refinement of the functional modeling of the gas turbine, its internal 
structure with its individual components (compressor V, combustion chamber B and turbine T), is 
considered in Frohn (1977) in more detail. The resulting modeling is shown in fig. 6. The underlying 
thermodynamic process is ideally assumed as adiabatic, reversible compression (l->2), isobaric heating 
(2-^3), adiabatic-reversible expansion (3->4) and isobaric cooling (4-^1). The modeling equations 
stemming from in depth thermodynamic studies of the individual components, see Frohn (1977), are 
indicated using the appropriate index V, B or T. 



= m<vTa|(|)-l} (9) 

Qb — mCp{T3-T2) (10) 

Wt = mcpTaK^)-!} (11) 

However, this exact knowledge is not necessary for the establishment of the evaluation method. For this 
purpose, only the functional modeling of the three design object components, i.e. of the compressor V, 
the combustion chamber B and the turbine T, in the form of the three relevance lists 

Mm,Cp,Ti,lFv,T2) = 0 (12) 

fB{m,Cp,T2,QB,Tz) = 0 (13) 

Mrh,Cj,,T3,WT,T,) = 0 (14) 
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Table 2 Dimensional Matrix Computations 
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needs to be known. According to these three given modeling equations (12), (13) and (14), three dimen- 
sional matrices for compressor (V), the combustion chamber (B) and the turbine (T) can be constructed 
according to fig. 3. The results are shown in table 2. For each of these three dimensional matrices F, B 
and T with rank r = 3 and n = 5, two dimensionless products are generated by the appropriate rank 
preserving operations on each dimensional matrix. Once the exponents aji in the dimensional matrix are 
determined, the dimensionless products au^cording to equation (2) are found to be equal to 



Wv 

= mCpTi 


(15) 


T2 

= jr 


(16) 


- Qb 

“ mCpT2 
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Ts 
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(20) 



The resulting evaluation hierarchy is now shown in fig. 7. In this figure, the corresponding abstraction 
levels of the mapping of the description graph onto the evaluation graph are shown. According to fig. 2, 
the transformation functions v?o and ipj coincide with the established dimensionless quantities ttj . The 
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Figure 7 Two-step Evaluation Hierarchy 



aggregation function (ps of the various partial evaluations into a complete evaluation is not yet determined, 
since this would require the knowledge of the function F{7rGi,Trv2i'^B2iT^T2) = 0. This can only be 
done using theoretical knowledge or experimental data. From the assumption of ideal gases, the global 
evaluation from the detailed description of the gas turbine is determined by equation (7). By substituting 
all dimensional quantities into each other, one obtains 



nth 



7Tt2 - {t^V2 7TB2) ^ 



(21) 



It is important to note that the individual nodes of the evaluation graph possess the property of min- 
imality and completeness. Thus, the influence of various changes of the design parameters can now be 
studied. If an even more detailed description of the functional modeling of the gas turbine is sought (poly- 
tropic thermodynamic process modeling, . . .), additional dimensionless products for the evaluation model 
would be obtained. The evaluation model would reflect these additions by the introduction of additional 
hierarchy levels. The evaluation model hierarchy can thus be extended consistently, see Rudolph (1995a). 



5 DISCUSSION AND CONCLUSION 

The example of the gas turbine evaluation also highlights another source of current misunderstanding 
and confusion in many engineering design evaluation models concerning the term design description 
(i.e. the xi, . . . , x„) and the term design evaluation (i.e. the tti, . . . , 7t„,). There exist many gas turbines 
generating different output powers Wn from different amounts of energy Qb, but if the numerical value 
of the (dimensionless) efficiency ratio ttgi = Wn/Qb turns out to be the same (i.e. is constant), all these 
different gas turbines are said to be of the same quality (=efficiency). The output power Wn alone is 
therefore clearly a design description parameter, which cannot serve for design evaluation purposes by 
itself, since its numerical value depends on the arbitrarily chosen physical units (see section 2). 

The evaluation method links the problem of design evaluation to the problem of design description. 
This means that the design evaluation changes exactly in these cases, where the design description is 
modified. Such modifications may include an 

• extension of the relevance list of the design parameters x*, which adds one or several lines to the 
dimensional matrix and finally leads to additional Wj as stated in section 4 (granularity), 

• adaption of every set of tti , . . . , to the corresponding set of design parameters xi , . . . , x„, since the 
problem of evaluation is basicedly reduced to a problem of description, see Rudolph (1995a). 




134 



Part Two Methodologies for Knowledge Intensive CAD 



These features are independent of the explicit knowledge of /, since every point set , . . . , a;„ taken from 
experiments or gained in simulations implicitly satisfies / and can be mapped without explicit knowledge 
of / onto the corresponding point set tti , . . . , 7r„i in dimensionless space. The method of dimensional 
analysis can therefore handle many design cases in which the underlying equations and interactions 
among the design parameters are not (explicitly) known and/or are being discovered during the design 
process. 



CONCLUSION 

By interpretation of the postulated evaluation hypothesis, it is most interesting to note that it can be 
shown in a rigorous sense, that an evaluation is only possible if a complete description in the form of 
functional relationships of the design parameters is known. Since complete functional descriptions are 
generally difficult to obtain, incomplete descriptions in the case of complex design problems will neither 
allow missing technical aspects to be evaluated, nor give a complete set of dimensionless products. This 
fact, however, is not a specific weakness of the suggested approach, but reflects the incomplete modeling 
of the physical phenomena. 

Even though the method puts a lot of emphasis on a clear understanding and a complete description 
of the problem, dimensional analysis based on the Pi-theorem has always been a valuable tool for en- 
gineers facing and investigating complex technical problems. Proving the completeness of the relevance 
list , . . . , of parameters is restricted to areas of “sharp” physical knowledge, but the method with 
its property as a mathematically necessary condition cannot lead to formal contradictions by itself. This 
makes the method also a versatile tool in areas of “unsharp” physical knowledge. In fact, engineers are 
usually very good at estimating the relative importance of physical design parameters in all kinds of 
problems which are theoretically not yet solved. An evaluation method based on the sound establishment 
of the relevance list xi, . . . ,r„ is therefore likely to be applicable in many engineering design cases. 

Due to the identical mathematical formulation, the link between classical similarity methods and the 
new design evaluation methods becomes evident. Such a consistent formulation might ease the application 
and the understanding of future design systems combining these features. The implementation of the 
evaluation method into a software tool is described in Rudolph (1995b). In this software module, the 
manual selection of the design variables xi,...,x„ takes the designing engineer very little time. The 
system then automatically generates the evaluation parameters tti , . . . , 7r„i from equation (2) and the 
sensitivity analysis from equation (4). Once the evaluation module is incorporated into a CAD-application 
program, it is hoped that the nowadays still manual selection process of the design evaluation parameters 
can be further automated, despite the fact that modeling seems to be a highly demanding cognitive 
process even many humans are not good at, see Rudolph (1995b). 

The serious investigation of the suggested evaluation method based on functional modeling in more 
complex applications may therefore be of general interest to the advancement of engineering design and 
design evaluation in the future. 
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Abstract 

Knowledge intensive engineering is a new style of engineering in which engineering knowl- 
edge is used in a flexible and integrated manner and aims at generating more added value. 
A Knowledge Intensive Engineering Framework (KIEF) is a computational framework for 
knowledge intensive engineering. To develop KIEF, we have to build a Very Large-scale 
Knowledge Base (VLKB) that contains a wide variety of engineering design knowledge, 
from commonsense knowledge about the physical world to domain specific knowledge sys- 
tematized as physics theories. VLKB for KIEF has a system of fundamental concepts 
called “ontology.” This paper describes the role of the ontology in KIEF, and validates 
the effectiveness of our approach through case studies. 

Keywords 

Ontology, Very Large-scale Knowledge Base, Knowledge intensive engineering 



1 INTRODUCTION 

Knowledge intensive engineering is a new style of engineering in which engineering knowl- 
edge is used in a flexible and integrated manner and aims at generating more added value 
(Tomiyama et al, 1994). A Knowledge Intensive Engineering Framework (KIEF) is a 
computational framework for knowledge intensive engineering (Tomiyama et al, 1996). 
Figure 1 shows the concept of KIEF, in which various engineering models play a crucial 
role to conduct innovative engineering activities over product life cycle including design, 
manufacturing, operation, maintenance, and recycling. 

To develop KIEF, first we have to consider the problem of how to deal with a wide 
variety of engineering design knowledge, from commonsense knowledge about the physical 
world to domain specific knowledge systematized as physics theories. Developing KIEF 
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Figure 1 Knowledge Intensive Engineering Framework (Tomiyama et al, 1994) 



requires to build a Very Large-scale Knowledge Base (VLKB) for dealing with a wide 
variety of product life cycle knowledge which is shared by participants in every stage of 
product life cycle (Ishii et al, 1995). However, building such VLKB is not an easy task. 

VLKB for KIEF has a system of fundamental concepts called “ontology” representing 
knowledge about the physical world. The word, “ontology” is used with various definitions 
by different research groups. It is proposed as a definition for the Al community that 
“Ontology is a specification of a conceptualization” (Gruber, 1992a). The PACT project 
regards ontology as sets of agreed-upon terms and formally described meanings of design 
domain (Cutkosky et al, 1993). Ontology is used as a common commitment among agents 
which manage the design tools. Defined such, ontology is required to supply a standard 
vocabulary. 

In our point of view, ontology generally exists independently of its expressions and 
representations. The knowledge available in KIEF is based on the ontology we supply, and 
the ontology is used for constructing a particular model and for maintaining relationships 
among various modelers. Therefore, the ontology provides a standard vocabulary as well 
as description about the physical world. In this paper, we describe the ontology for KIEF 
which was built and verified through our case studies. Prior to our study, there were 
several projects conducted towards construction of VLKB that can handle real world 
problems. The Cyc Project conducted at MCC (Lenat and Guha, 1989) and the How 
Things Work Project at Stanford University (Gruber, 1990) are examples of such projects. 
The Cyc Project aims at first codifying the fundamental knowledge which is common 
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sense knowledge students should have before learning specific domains, such as notions 
of time, space, and causality. Then, the knowledge base is expected to easily acquire 
domain specific knowledge (even with machine learning technology). The How Things 
Work Project aims at collecting knowledge that explains how physical mechanisms work. 

In contrast, our work does not directly aim at knowledge collection itself, but rather 
builds an ontology and a framework for collecting knowledge. “Knowledge collection by 
modeling” can be performed on our framework. In this regard, the ontology reported in 
this paper can be compared with Ontolingua (Gruber, 1992b). 

This paper is divided into five sections. After this introduction. Section 2 briefly de- 
scribes the architecture and mechanisms of KIEF. We also illustrate the framework of 
the ontology and discuss its roles in KIEF. Section 3 describes case studies of modeling 
process on KIEF. We demonstrate how to use our ontology in modeling processes, and 
discuss the power of our approach in collecting design knowledge. Section 4 validates the 
effectiveness of our approach by demonstrating the reusability of the ontology stored in 
the VLKB. We will observe that, even though the size of the ontology is fairly small, it is 
still effective. Section 5 concludes the paper. 



2 THE KNOWLEDGE INTENSIVE ENGINEERING 
FRAMEWORK 

KIEF aims at allowing participants in a product development process to share knowledge 
about the product life cycle. STEP has a similar goal to our research, but emphasizes 
on serving as a data model for product modeling. The aim of KIEF further extends to 
explanation and theory behind product models. For example, it is difficult for production 
engineers to understand behaviors and functions of a design object from its drawings as 
deep as its designers. They can, however, simply understand designers’ intention, if they 
can perform behavior simulation of models. The purposes of this research therefore include 
sharing knowledge and seamless exchange of design information among various models. 

A specific model, which we call an aspect model, has a specific purpose. For instance, a 
kinematic model simulates the kinematic behavior of the object, and a geometric model 
represents its shape. Therefore, a variety of models will be needed to represent a product 
during its life cycle. Although they represent an identical object in the real world, within 
the computer there is no universal interface directly connecting them, nor universal prod- 
uct modeling scheme. This means that, although models are practically connected with 
each other, it is hard to maintain or to verify the relationships among them. We consider 
that ontology must serve as a fundamental mechanism to maintain such relationships. 

Therefore, ontology plays two crucial roles in KIEF. One is to serve as a basis of VLKB 
defining a wide range of knowledge including fundamental rules about physical world. 
The other is to provide the multiple model management mechanism with the fundamental 
knowledge about relationships among various aspect models. 

2.1 The Pluggable Metamodel Mechanism 

A design object can be represented with aspect models that encompass a wide variety 
of dimensions, i.e., domains of concepts for modeling, levels of abstraction, and levels 
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of approximation. For instance, domains include function, geometry, and kinematic. A 
functional model represents the function, a geometric model represents the shape, and 
a kinematic model represents the motion of the design object. A beam model and a 
finite element model are used to evaluate strength at different levels of abstraction. A 
kinematic model with or without friction is used to evaluate motion at different levels 
of approximation. These aspect models are not independent of each other. Therefore, we 
need a mechanism to maintain the consistency among aspect models. 




□ 



external model 




interface 



Figure 2 The pluggable metamodel mechanism (Ishii et al, 1995) 

The metamodel mechanism is a modeling framework to integrate multiple a.spect mod- 
els (Tomiyama et al, 1989, Kiriyama et al, 1991). It has symbolic representation of 
concepts about physical phenomena and components (See Figure 2). A metamodel of a 
design object is represented as a network of relationships among concepts that appear 
in the aspect models. Types of relationship include causal dependency among physical 
phenomena, arrangements of components, and quantitative relationships. These concepts 
and relationships constitute the ontology of KIEF. 

An aspect model is, however, usually dealt with by an existing external modeler. There- 
fore, it is desirable if we could plug in such existing modelers to KIEF. The pluggable 
metamodel mechanism allows easily plugging in external modelers (Yoshioka et al, 1993). 
In order to plug an external modeler into a pluggable metamodel mechanism, three kinds 
of knowledge have to be prepared. One is descriptions about concepts which are used by 
an external model. The second is descriptions about concepts which are available from 
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other modelers through the metamodel mechanism. The third is descriptions about cor- 
respondences among concepts in the metamodel and model fragments used to construct 
an external model and procedures to translate between a concept in the metamodel and 
one in a model fragment. A model fragment is stored in the model libraries and used by 
an external modeler to build an external model. While more details are explained in the 
next section, here we just point out that concepts included in the these three kinds of 
knowledge and defined as the ontology. 

2.2 The Architecture of VLKB 

VLKB for KIEF should support model-based reasoning mechanisms, and supply funda- 
mental knowledge about the physical world. Figure 3 depicts the architecture of VLKB 
to do so. VLKB consists of three layers. In the middle layer, there is a concept base which 
contains concepts about entities, physical phenomena, relations, and attributes. The up- 
per layer contains physical features that are combinations of physical concepts. The lower 
layer contains physical laws that are used as model fragments for various aspect models 
(Ishii et ah, 1995). 

The concept base contains names of physical concepts and relationships among physical 
concepts. The relationships include an abstract-concrete hierarchy of physical concepts, 
differential relations between attributes, and “has” relations between entities and physical 
properties. 

In the upper layer, physical features are built and stored in the physical feature knowl- 
edge base. The concept base provides only vocabulary of physical concepts such as “burn,” 
“fuel,” “warm up,” and “air.” Physical features are the statements that describe phys- 
ical situations, such as “fuel burns, generates heat, and warms up air.” The designer 
constructs a metamodel with physical features; that is, physical features are building 
blocks of a metamodel. This idea is largely based on Forbus’s Qualitative Process Theory 
(Forbus, 1984). 

In the lower layer, physical laws are described. The same physical law can be differently 
represented in different aspect models. The physical rule KB contains unique names of 
physical laws and the attribute concepts used in the laws. The names of physical laws 
keep track of the same physical law represented in different aspect models. 

The model libraries store typical model fragments of external model, which correspond 
to physical concepts. For example, an equation 



/ = ma 



is a fragment of a dynamics equation model that describes Newton’s Second Law. These 
fragments are used as building blocks to generate external models. To generate an external 
model, first relevant concepts are collected to form an aspect model in the metamodel level. 
The parameters used in a fragment correspond to attribute concepts, so after an aspect 
model is generated, the metamodel mechanism translates the concepts in the aspect model 
into the terminology of the corresponding external model and maintains relationships 
among the attribute concepts in the metamodel and the parameters in the external model. 
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Figure 3 The Architecture of VLKB (Ishii et al, 1995) 



2.3 The Ontology for KIEF 

We consider that ontology is a system of the fundamental concepts about the physical 
world. The ontology for KIEF is stored in the concept base described in the previous 
section. It includes five kinds of concepts; namely entities, relations, attributes, physical 
properties, and physical phenomena. Each of these concepts is separately categorized and 
forms a static conceptual network. 



• Entity 

An entity represents an atomic, physical object in our representation. Entities are 
organized in an abstract-concrete hierarchy. For example, a “worm gear” is a subclass 
of a “gear.” This implies that physical phenomena that occur on a gear pair also occur 
on a helical gear pair. The hierarchy allows multiple inheritance. 

• Relation 

A relation represents a relationship among entities, such as “on,” “above,” “below,” 
and “connection.” In other words, it defines the structure among entities. 

• Attribute 

An attribute is a concept attached to entities and takes a value to indicate the state of 
entities, such as “position,” “temperature,” and “mass.” 

• Physical Property 

A physical property is a concept that describes a generic characteristic of entities such 
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as “elcistic” and “magnetized.” A physical property is associated with a set of attributes 
that indicates degree of the physical property. 

• Physical Phenomenon 

A physical phenomenon designates physical laws or rules that govern behaviors. A 
physical phenomenon is defined by the following slots: 

- Name of the physical phenomenon. 

- Super (or abstract) physical phenomena. 

- Prerequisites for the physical phenomenon to be activated in terms of entities to- 
gether with their attribute definitions, relations, and physical properties. 

- Physical laws that define relationships among the parameters and define influences 
that can happen when the physical phenomenon is activated. 

3 CASE STUDIES 

Building VLKB is labor- and resource-consuming. To validate our ideas, we need to eval- 
uate burdens to build VLKB and to define and collect ontology for practical applications. 
More importantly, if the constructed ontology is not reusable, the whole idea is not useful. 
The section discusses this issue through two case studies, i.e., modeling a motorcycle and 
a contactor. Each case study proceeds with the following steps. 

1. Build a metamodel. 

2. Build a solid model. 

3. Derive a set of physical equations that represents relevant physical phenomena. 

In the case studies, we plugged a dynamics modeler and a solid modeler into our plug- 
gable metamodel mechanism. The dynamics modeler is built on Mathematica* to assist 
a designer to derive motion equations from the metamodel and to evaluate them. We also 
use DESIGNBASEt, which is a commercial solid modeler. 

3.1 The Motorcycle Case Study 

Building a Metamodel 

First, the designer inputs a primary model of a motorcycle with physical features. A 
primary model represents a mental model of the designer and serves as an input to the 
metamodel mechanism to generate a metamodel. The designer selects physical features 
from the physical feature knowledge base to express the motorcycle. He/she doesn’t have 
to deal with physical concepts directly, if the concept base has sufficient ontology. 

We suppose that the motorcycle consists of two wheels, two dampers, two springs, and 
one body (See Figures 4 and 5). At each connection between two parts, force is transmit- 
ted, and these parts never separate. We call such connection “ForceFixedConnection” in 
this case study. The behavior of a motorcycle is expressed by several physical phenomena, 
such as “Damping,” “ElasticTransformation,” “LinearMotion,” and “RotationalMotion.” 

* Mathematica is a trademark of Wolfram Research, Inc. 

^DESIGNBASE is a trademark of RICOH Corporation. 
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Figure 4 The Primary Model of a Motorcycle 



After building the primary model, the system generates a metamodel from the pri- 
mary model. This process is divided into two sub-processes. First physical phenomena 
are added to the primary model, which the system finds out occurring to the primary 
model but the designer did not notice while building the primary model. The metamodel 
mechanism performs this process by pattern matching between the primary model and 
physical features. Second, attributes are instantiated by examining the definition of each 
of physical phenomena which form the primary model. Through this process, relationships 
among attributes are also instantiated. In this example, some attributes such as “posi- 
tion,” “velocity,” “force,” and some relationships among attributes such as Newton’s Law 
(which gives the description that there are relationships among “position,” “mass,” and 
“acceleration”) are instantiated and added to the metamodel of a motorcycle. 

Now, the metamodel contains part of the concepts that define the motorcycle, relations 
among them, attributes that are used to express the behavior of the motorcycle. 

Building a Solid Model 

Next, the designer builds a solid model in Figure 5. Independent of the metamodel, the 
designer defines shape of each component, and then he/she makes correspondences be- 
tween an entity concept in the metamodel and a solid. Figure 6 is a screen hardcopy of 
the “matching interface” used to match a solid with an entity concept, and parameters 
in each solid with an attribute concept. For example, the front wheel shown in the Figure 
5 corresponds to an entity concept, Wheels in the metamodel, and the position of the 
solid corresponds to an attribute concept. Position^ of Wheel. The solid modeler obtains 
the position of a front wheel from the metamodel mechanism using the attribute concept 
as the key. When the designer builds a model independent of the metamodel as in this 
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Figure 5 A Solid Model of the Motorcycle 



case, he/she has to define the correspondence between a concept in the metamodel and 
an element of an aspect model. 

Building Motion Equations 

In the metamodel, the behavior of motorcycle is represented by physical phenomena, and 
each phenomenon is defined in VLKB using physical laws. When an external modeler 
composites an external model, it checks the relationships among concepts in the meta- 
model. Figure 7 shows the hardcopy of the dynamics modeler. The conceptual network 
in the upper half of this figure represents attributes and the possible relations among 
the attributes about the motorcycle, which are a part of the metamodel. The designer 
interacts with this modeler through the lower half, examines the equations the modeler 
gives (the lower left lists), and modifies them if necessary. The lower right lists attributes 
existing in the equations. The work flow to set up equations is as follows. 

1. Setting parameters. 

The dynamics modeler prepares parameters that can be used for equations by instanti- 
ating each parameter from the corresponding attribute in the metamodel. In this way, 
another modeler obtains the value of a parameter calculated by the dynamics mod- 
eler by simply accessing the corresponding attribute concept in the metamodel to the 
parameter. 

2. Building physical equations. 

The metamodel mechanism stores attributes and relationships among attributes, such 
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Figure 6 The Interface for Matching a Solid with an Entity Concept: “Body 12657” 
designates the motorcycle body which is “solidl” in the solid model. 



as physical laws. The model library for the dynamics modeler contains quantitative 
expressions of the physical laws, so the modeler replaces a physical law with a quanti- 
tative expression using this knowledge. For example, the dynamics modeler translates 
“Hooke’s Law” expressed in the metamodel into an equation 

f = —kx. 

Given “Second Law of Newton’s Laws,” the process is a little more complex. The 
modeler knows the equation 

F = ma, 

which describes Newton’s Law, and F is resultant force that is defined in the concept 
base. When the dynamics modeler finds Newton’s Law in the metamodel, it searches 
attributes whose names are “force” and are attached to the entity connected with the 
law. Then, the modeler builds an equation such as 



/l + /2 + ••• + /n — 



by combining all the relevant forces. 

3. Modifying the equations. 

The designer modifies or arranges the given equations if necessary, because the meta- 
model mechanism currently cannot deal with spatial information of objects perfectly. 
Then the designer confirms the obtained equations. 

4. Building the equations. 

The modeler passes the motion equations to Mathematica, which first simplifies the 
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Figure 7 A Hardcopy of the Dynamics Modeler 



equation. Figure 8 shows the equations (hand- assembled and simplified for the sake of 
readability). 



Solving the Motion Equations 

Next, the metamodel mechanism supplies the values of the parameters in the obtained 
equations, for example, from the geometric modeler. However, some values (such as vis- 
cosity) cannot be obtained in this way. In this case, the designer specifies the values. Then, 
Mathematica solves the equations. Figure 9 is a solution graph obtained by Mathematica. 
It shows the displacement and the rotation of the center of gravity of the motorcycle body, 
assuming that the motorcycle is running on a washboard. 

The dynamics modeler can then give back the solution to the solid modeler for vi- 
sual simulation. Figure 10 is the screen hard copies of the behavior simulation of the 
motorcycle. This is obtained in a simulation process depicted in Figure 11. 
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Figure 8 Motion Equations of the Motorcycle 
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Figure 10 A Behavior Simulation 




Figure 11 The Simulation Processes 



3.2 Modeling a Contactor 

We also modeled a contactor, which is a kind of electromagnetic switches. Figure 12 
depicts a rough sketch of the contactor (Ranta et al, 1995). We constructed a primary 
model (see Figure 13). The modeling process of the contactor is not different from that 
of the motorcycle, so we skip the details. 
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Figure 13 The Primary Model of a Contactor 
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4 DISCUSSIONS 

In this section, we validate the effectiveness of our approach by demonstrating the reusabil- 
ity of the ontology stored in the concept base. The concepts used for the case studies in 
Section 3 are not specialized to particular models, and they are reusable enough for mod- 
eling various kinds of design objects. Figure 14 shows the partial hierarchy of the entity 
concepts. The names circled, “Body,” “Damper,” “Spring,” and “Wheel” are used to 
model the motorcycle. The names surrounded in a rectangle are used to model the con- 
tactor. Although the motorcycle and the contactor are substantially different, “Spring” 
is used by the both (See Figure 14). One recison for this is that in the primary design 
stage, concrete concepts are not used to represent the design object, because the designer 
cannot define its details yet. 

The system can define multiple inheritance which increases the reusability of the ontol- 
ogy. Sub-concepts inherit the character of their super-concepts. This signifies that “the 
phenomenon which occurs to a super-concept will occur to its sub-concepts.” For example, 
physical phenomenon named “LinearMotion” occurs to both “Body” of the motorcycle 
and “Cross Bar” of the contactor, because their super-concepts include the same concept 
“Mass.” 

Of course in the detailed modeling stage, the designer may no longer use general con- 
cepts such as “Spring,” but use more concrete concepts. These concrete concepts are more 
specialized to the modeling object and less reusable. Note that, the motion equation deals 
with a “Damper,” rather than “Air Damper” or “Oil Damper.” (Strictly speaking, the 
behavior of a damper may be quite different depending on what is contained in its cylin- 
der.) That means the difference between the two concepts are not concerned on this level 
of modeling, but the definition of “Damper” which is their super-concept is the matter 
and was useful for the case studies. This resulted in fewer concepts for modeling than we 
had initially imagined. 

We have collected physical concepts from literature such as engineering textbooks (e.g. 
(Hix and Alley, 1958)), but did not need so many for modeling of the case studies. Table 
1 shows the numbers of concepts we have collected, and the numbers of concepts we used 
or we referred to for the case studies. For example, we have collected about 250 entities, 
but 8 kinds of entities were used to model the motorcycle, 14 kinds of entities were used 
for the contactor, and 5 kinds of them were commonly used. Despite the fairly small size 
of the knowledge base, it sufficed for the modeling processes. This indicates the reusability 
of our ontology, and at the same time implies that knowledge collection for KIEF can be 
done during modeling processes. 

We summarize the advantages of having ontology as follows. First, because the ontology 
supplies various engineering models with common concepts, models can share information 
about objects, such as quantitative values. Second, the ontology provides general concepts, 
like standard parts of machines. Third, the ontology supplies the abstract-concrete hier- 
archy that increases the reusability of knowledge. 

Through the case studies, we experienced some problems. Among others, the most 
critical was the lack of spatial concepts. In order to treat spatial information on the 
metamodel, we have to systematize spatial concepts and to implement more convenient 
interactive tools. 
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Figure 14 Part of an Entity Hierarchy 
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Table 1 The Number of Concepts Used for the Case Studies 



Physical concept 


Total Number of Concepts 


Concepts used for 


Source 


in the Concept Base 


Motorcycle 


Contactor 


Both 


Physical Phenomenon 


150 


4 


7 


2 


a text book about tools and machine 


Entity 


250 


8 


14 


5 


and some examples of real products 


Relation 


40 


1 


4 


1 


mainly spatial relations 


Attribute 


280 


11 


13 


7 


text books of dynamics, kinematics, etc 


Physical Property 


80 


3 


6 


2 


text books of dynamics, kinematics, etc 


Physical laws 


300 


4 


6 


2 


"Physical Laws and Effects" 



5 CONCLUSIONS 

This paper first introduced the concepts of KIEF and discussed the roles of ontology 
in KIEF. Ontology is needed to define fundamental knowledge for KIEF and to allow 
knowledge sharing within the multiple model environment of KIEF. We then described 
the ontology for KIEF. To validate the idea of our approach, we conducted two case studies 
to model a motorcycle and a contactor. Each case study involved building a metamodel, a 
solid model, and a dynamics model. This demonstrated the power of KIEF which allows 
flexible knowledge sharing and reuse among various engineering models. 

We collected physical concepts from literature such as engineering textbooks, but the 
concepts needed for the case studies were fewer than we had imagined. This suggests that 
collecting knowledge for KIEF can even be done through modeling processes. 
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Abstract 

A catalog is a basic resource to a number of people and disciplines ranging from shoppers 
to companies wanting to sell products. They have traditionally been in paper form and are 
due for rapid revolution in content and presentation because of the existence of the 
Internet and the World Wide Web. This paper deals with one component in such a 
revolution; a component aimed, initially, at aiding the design engineer and later other 
users. 

Today’s engineering design methodology, in the search for minimum time-to-market, 
emphasizes reusing existing reliable components wherever possible. This, in turn, 
requires components to be described in forms useful to the engineer and in forms that 
help in finding the information about the component in the first place. It also raises new 
challenges in support for not only efficiently retrieval of information but also for 
powerful mechanisms for information evaluation and consumption. Although rich in 
content, today’s catalogs and libraries of catalogs and other information are poor in using 
domain knowledge to help designers to access information in catalogs and libraries 
during the course of a design. Consumption (in the engineering case) requires the 
descriptive information to be incorporated not only in documents and drawings but also 
in simulations of as many modalities as are deemed necessary for performing the 
engineering task. 

In this paper, we describe a prototype system. Active Catalog, that utilizes a rich body 
of domain knowledge to facilitate the access and consumption of library contents. The 
domain knowledge-base system provides a vocabulary that is at a much higher level of 
conceptualization than that used by traditional database query or the key-word match 
technique widely employed by Web applications. Based on the knowledge of the domain 
and the meaning of the queries specified in this vocabulary, a search engine accesses 
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library components that satisfy the semantics’* defined by the queries. In addition, 
Active Catalog, suggested by its name, adds to traditional library contents such as 
textual and image information, a rich set of models of different modalities. The system, in 
turn, allows a designer to down-load models, viewers, running code or simulation code to 
evaluate dynamic and behavioral aspects of a cornponent in a systems environment via 
interactive simulation before committing the component for prototype or production use. 

Active Catalog methodology of use supports a new “Try-Before- You-Buy” 
methodology. 



Keywords 

Knowledge-based Information Retrieval, Semantic Network, Database-Knowledgebase 
Integration, Design Library, Simulation-based Design. 



1 INTRODUCTION 

Today’s design environments must provide the designer with, in addition to traditional 
tool, libraries and catalogs of reusable components in relevant design domains (Will 
1991). AUTODESK’S Parts Library (PartSpec) for mechanical design and SmartModel 
Library (PartSpec) for circuit design are examples. The major benefits of using libraries 
and cat^ogs are well-known: the products, designed with reusable components, are 
cheaper, better and faster-to-market. With the ability to save partial designs, designers 
could cache information for future applications and thus, bootstrap their effort. 

Most of the benefits of catalogs and libraries are based on a major prerequisite: that the 
information is easily and conveniently accessible to the designer (i.e., it is reachable and 
usable). This assumption does not naturally hold in general. Although rich in content, 
today’s libraries are poor in access and their contents are designed to be consumable by a 
human reading a document or looking at an image. The design domain is one where the 
information is to be automatically consumed by a computer and is harder. This poor 
situation would be improved a) by using domain knowledge to give designers easier 
access to library contents during the course of design and b) by improving the means of 
consumption of the information by computers after it is retrieved. 

There exists a gap between the high-level, conceptual mental model of a part needed by a 
designer and the low-level, physical query that retrieves the needed information from a 
library. Too often, the designer is required mentally to map the description of a desirable 
component for solving a particular problem onto a set of searchable attributes 
recognizable by the library/catalog. That is, the user needs essentially to understand the 
“schema” of the libraries and the searchable technical attributes of the library contents 
before mapping the need into a set of queries. This mapping is not trivial and imposes a 
major mental burden on designers, deflecting them from focusing directly on solving 
their design problem. Using the information from the library/catalog is equally onerous 
and often involves manually transcribing the information into the local design tool 
environment. This is especially true when the data must be entered into CAD or be 
prepared for consumption by distributed simulation environments. 
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In this paper, we describe a prototype system, Active Catalog, that addresses the above 
problems by using a rich body of domain knowledge to describe the library components, 
adding to and annotating traditional library information and aiding the use of the retrieved 
information in CAD applications. Designers, using the system, can search library 
contents using the familiar terminology of the design domain. A search engine, based on 
the knowledge of the domain and the meaning of the queries specified in the domain 
vocabulary, accesses library components that satisfy the functionality meant by the 
queries, rather than by matching the keywords or synonyms in the queries. Active 
Catalog, suggested by its name, adds to traditional library contents (such as textual and 
image information), a rich set of models of different types that, in turn, allow a designer 
to evaluate dynamic and behavioral aspects of a component in a system via interactive 
simulation built from or using down-loaded models, viewers or even applets of simulation 
code. 

The goal of this research is to improve both design environments and the general 
consumption of information found in catalogs and libraries. We approach this goal, done 
here in the context of electro-mechanical engineering design, by addressing several 
fundamental HCI, cognitive issues. As noted, there can be a gap between the user’s 
mental model of a part and the set of queries needed to access it. We humans cannot 
perform high quality reasoning and provide correct judgement if there exists no direct 
mapping between a real world object and our mental model of that object; and we are 
much less productive when we are diverted by too many distracting tasks; we cannot keep 
track of many threads or recall all what we know. Last, but not least, we cannot access 
material if we are not aware of its existence. We aim at providing technologies that enable 
designers to dedicate their mental resources to the design problems at hand and are using 
a knowledge-based approach to do it. 

The rest of the paper is organized as follows. We first give an overview of the system 
architecture by illustrating system substrates. We then describe in detail the key relevant 
system components. These components include a semantic network of the domain that 
enables a high-level, flexible, and user-centered approach to information query; a 
knowledge-based search mediator that hides distributed and heterogenous information 
sources from a user; and a set of middle-ware that enables a distributed simulation 
environment to assist in evaluating the dynamic and behavioral aspects of a piece of 
information retrieved. One section will be dedicated to each of these components, 
followed by reviewing of related work and our future directions. 



2 OVERVIEW OF THE SYSTEM STRUCTURE 

An Active Catalog, as the name suggests, is a normal catalog enhanced by information 
that is dynamic in one or several dimensions. The word active is used to connote the idea 
that the information is not static, pre-canned sequences of descriptions of the data in the 
catalog, (nor merely regular multimedia: whether sound, image or movie) but may itself 
contain information that can, in turn, compute the required answer or even be used to 
compute the answer. The computation can be done either: 
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• in the output stage of the search and thus be dynamically tuned and delivered, or, 

• in the recipient’s local or distributed computing environment by delivering a program 
(perhaps a JAVA applet) for local use, or, 

• used to configure the users environment. 

In a design environment this takes the form, in the first implementation, of using 
components and parts described by a set of models of different modalities to make system 
simulation models and thus help the engineer produce better products. The types of 
models include, for example, a mathematical model, various kinds of simulation models, 
an engineering drawing, a 3D geometrical model, a transfer function model, kinematic 
and dynamic models, textual and semantic descriptions, a set of information viewers and 
even simulation code. 

The major components of an Active Catalog (FIGURE 1) are: 

• a semantic model of a domain, 

• a set of parts in the domain described as catalog entries, for each part a set of 
appropriate models in the modalities mentioned, 

• a set of databases that stores the models, 

• a search engine that recognizes users’ queries specified in a vocabulary given by the 
semantic model of the domain, and 

• a set of helper applications for viewing the information retrieved. 

Also provided is a set of application programming interfaces (API) to facilitate the 
integration of a parts from a catalog, or even the catalog itself, into engineering and 
electronic commerce environments. 

A user is anticipated to be an engineer doing a new design, a repair/maintenance person 
maintaining a product or a potential buyer wishing to test a component before buying it. 
This “Try-Before- You-Buy” paradigm may well be the most important outcome of the 
work described here and has wide applicability. The user, as shown in FIGURE 1, can 
either browse catalog contents or issue high-level conceptual queries for the desirable 
information. A knowledge-based search engine, taking as input the user’s high-level 
query and the domain knowledgebase, matches catalog contents with the semantics of the 
query. When a piece of information is returned by the search engine, the system extracts 
retrieved information of different types and dispatches it to the corresponding software in 
the users’s environment such as simulators, spread-sheets, helper applications and 
viewers that handle the appropriate modality. When necessary, a distributed simulation 
environment can be automatically configured and executed. 

We will focus in the following sections on the capability of an Active Catalog in 
providing knowledge-based catalog and library support to the engineer. 



3 THE DOMAIN 

The domain of pumps will be used as an example through out the remainder of this paper. 




Database Server 
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Figure 1 Active Catalog Architecture: supporting information consumption 
from retrieval to application. 
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This domain was chosen for study in the context of simulation based design of 
electromechanical systems found in ship design and maintenance. Although the 
description of the work that follows is specific to pump systems, the technologies and 
mechanisms developed are domain independent and have wider applicability. The use of 
the system may be illustrated with reference to the example shown in Figure 1 . There the 
user is faced with a problem he or she needs a pump to solve an engineering problem. The 
user enters the catalog module and describes the query in any one of the several methods 
(described later). The system conducts a knowledge based search of a variety of catalogs 
available locally (or on the WWW soon) and then returns components matching the 
description including the description of the pump drive requirements, the geometric size, 
weight, connector needs etc. The user then does a Try-Before- You-Buy action by 
choosing to test the objects (the pump and a similarly chosen motor for example) returned 
in response to the query in a chosen simulation environment. The object describing the 
returned part is then examined and the various parts of it sent to the appropriate simulator. 
In the pump/motor example used here, mathematical and transfer function simulation 
models of both pump and motor are sent to MatLab/SimuLink (MatLab) for dynamics 
analysis while kinematic models for simulation of the pump pressure and stroke 
interactions are sent to WorkingModel (WorkingModel). 



4 SEMANTIC NETWORK DESCRIBING THE DOMAIN 

The key to knowledge-facilitated search for information is the existence of a semantic 
network (Brachman 1991) for the domain. It needs to describe: 

• taxonomies of the domain objects (parts and components in the catalog or library); 

• their attributes, values and value constraints; 

• taxonomies of the attributes, values and value constraints; and 

• relationships among these objects, attributes, and attribute values and value constraints. 
There are few semantic models of any domain in existence at present. The Ontology 
project at Stanford (Farquhar et al. 1995) provides a framework for unifying and 
disseminating models, but until a corpus of semantic models exist each new domain will 
have to be constructed as needed. Tools for the construction of semantic models are 
needed. 

In the case here, the semantic network is modeled in Loom (MacGregor 1990), a 
knowledge representation system language and environment developed at ISI for 
constructing intelligent applications. The Loom system provides deductive support for 
the declarative portion of the Loom language. Declarative knowledge in Loom consists of 
definitions, rules, facts, and default rules. The semantic model of pumps consists mainly 
of definitions and matches Loom’s power. 

4.1 Main Taxonomy for Pumps 

The main taxonomy of the semantic network describes pump types. It is similar to a 
typical product classification found in a traditional catalog, except that the classifications 
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Attribute Hierarchy 



Type Hierarchy 

Centrifugal Pump 

Axial Flow Centrifugal Pump 
Mixed Flow Centrifugal Pump 
Radical Flow Centrifugal Pump 
Screw Centrifugal Pump 
Special Pump 

Electromagnetic Pump 
Gas Lift Pump 
Hydraulic Ram Pump 
Jet Pump 
Pitot Pump 

Screw Centrifugal Pump 
Viscous Drag Pump 



Value Constraint 
Hierarchy 

Construction 

Casing Construction 
Coating And Lining Construction 
Impeller Construction 
Wearing Ring Construction . 
Driver 

Brake Horsepower 
Driver Position 
Driver Type 
Pitch 

Installation 

Geometry 

Mounting 

Weight 



Impeller Structure 

Impeller Structure By Flow Direction 
Impeller Structure By Openness 
Rotor Structure 
Bearing Structure 
Circumferential Piston Structure 
Diaphragm Structure 
Flexible Member Structure 
Gear Structure 
Lobe Structure 
Piston Structure 
Screw Structure 
Vane Structure 



Figure 2 Sample taxonomies of pump types, attributes and value restrictions from 
Active Catalog’s semantic network of the domain. 

are much more extensive. 

The pump taxonomy is organized as a graph rather than a tree structure. This provides 
multiple paths to a specific pump type and is implemented using LOOM’s multiple 
inheritance features. At the top levels of the taxonomy are a few abstract type-definitions 
for pumps, such as Kinetic Pumps and Positive Displacement Pumps, with Special 
Pumps, Peripheral Pumps and Centrifugal Pumps being subclasses of Kinetic Pumps, 
and Rotary Pumps, Blow Case Pumps, and Reciprocating Pumps being subclasses of 
Positive Displacement Pumps. In the middle levels are a rich set of abstract classes 
defining varieties of pump classes. At the bottom levels, a large number of pump classes 
are defined by combining types from top and middle levels. For example. Reciprocating 
Single Acting Power Multiplex Pumps are defined as sub-class of Reciprocating Pumps, 
Single Acting Power Pumps, and Multiplex Pumps. Figure is a small sample of the 
present pump taxonomy, which consists of more than one hundred pump types, in our 
semantic net, which has over a thousand entities. 

There are several benefits to making a taxonomy with a graphical structure. Since most 
bottom-level, specific pump types have multiple parents, the users of the taxonomy can 
reach the same target types via different paths. This enables the user to issue partially 
specified queries in terms of known pump types/features without sacrificing the capability 
of reaching the target. The taxonomy used in Active Catalog does not require its user 
to know and remember the exact types of the pumps needed. For example, a 
Reciprocating, Single Acting, Power Multiplex Pump is reachable via any of (or 
combination of) the following pump types: Reciprocating Pump, Single Acting Power 
Pump, Multiplex Pump, and all the pump types that are the parents (in the type hierarchy) 
of these three types. 
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4.2 Main Taxonomy for Attributes and Value Constraints 

Attributes describe properties of the objects in the semantic network. A unique feature of 
attributes is that, like pump types, they are organized hierarchically in the semantic 
network in order to facilitate query specification and reasoning. For example, the 
attribute. Pump Structure, is a high-level abstract attribute, with several sub-attributes: 
Propeller Structure, Prime Mode, Internal Structure, and so on. An attribute taxonomy 
allows queries to ask loosely for the Structure of a pump being of type Self-Priming or 
Peripheral rather than for the query to specifically ask for Priming Structure to be Self- 
Priming and Internal Structure to be Peripheral respectively. 

A value constraint specifies the range of all possible values for an attribute either in the 
context of a pump type or in a context-free form. All value constraints constitute the space 
of attribute values. As in types, the value constraints are organized hierarchically into a 
taxonomy. For example, the value constraint for the attribute. Casting Material of Pumps, 
is Solid Material, which could be Cast Iron, High Silicon Iron, or Naval Bronze. 

By combining the above taxonomies, the user can construct a specific query such as, find 
Pumps whose Casting Material is Bronze, or a more conceptual query. Pumps whose 
Structure is Corrosive-Resistant Material. {Bronze is also one of its sub-classes). Of 
course the first query is more specific and precise, however, it requires more knowledge 
about pumps and more skill to specify; whereas the second is easier to construct but will 
more likely return a larger set in the result,. Although both forms are needed, the second 
one is preferred in many situations since it requires less initial specificity. In general, it is 
much harder to generate a correct set of results by one precise query than to achieve the 
same set by filtering from a larger set of candidates (if the size of the set of candidate is 
manageable). 

Although seemingly more flexible and more user-friendly than traditional information 
retrieval, the queries so far are still described in terms of technical attributes. That is, the 
user is required to transform domain problem into technical attributes and terminology 
and to use technical-oriented vocabulary to construct queries. Users need to be able to 
state a query in the vocabulary of the applications domain. 

4.3 Semantic Network 

A semantic network, woven with the above (types, attribute, and value constraint) 
taxonomies, declaratively describes knowledge traditionally used by experienced 
engineers working in the domain. A declarative representation of such knowledge is 
easily sharable, transferrable, and maintainable; it can be used by computer programs to 
automate sophisticated, routine tasks that otherwise would have to be performed by the 
user. One such task is the mapping of a description of an engineering part or component 
that satisfies a domain need into a set of representations and queries that can be 
recognized and acted upon by the information sources storing the corresponding parts 
and components. 

Our current semantic network in Active Catalog captures a sub-set of the total 
knowledge of pump systems, comprising descriptions of pumps, motors used for driving 
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Figure 3 A fraction of pump knowledge from the semantic network in Active 
Catalog. 

them, their connections, and their applications. 

Figure graphically depicts a piece of the semantic network describing the relationships 
between pumps and motors and the relationships between the type of fluid to be 
transferred and the casting materials for pump. 

To avoid a lengthy discussion, we will not describe here every detail about the model but 
will focus only a few interesting points. First, the model has an open structure. It provides 
a template for expanding into a much richer and detailed network depending on the need 
of the application. For example, a model of fluid type, (corrosive, water-based, oil-based, 
rheological coefficient etc.), power source, casting material, corrosive resistant casting 
material, or connector can be added to enrich the depicted model. 

Second, the model captures knowledge about applications. For example, the network 
contains a piece of deductive information that if a pump is used to transfer corrosive fluid, 
then the pump’s material should be corrosive-resistant. In fact, our network provide a set 
of different types of corrosive fluid, corrosive resistant materials, and a set of correspond 
implication rules. Users can then directly describe the use of the pump in application 
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terms, such as find a high capacity pump for transferring sea water or find a motor that 
drives a high-capacity centrifugal pump, without having to know the exact technical 
terms for describing pump parameters. 

Third, the network facilitates information access even if the existence of the information 
is unknown to the user. When a new type of material becomes available we make the new 
material retrievable by simply adding the model and implication rules for the new 
material without touching other parts of the network. All the changes are then transparent 
to the end user. That is, even in the case of repeating an old query, the system will 
automatically reply with the new material even though the user may not be aware of its 
existence and its availability. 

Fourth, the semantic network captures the underlying semantics of the domain and is 
sharable across domains. 

5 USER-FOCUSED QUERY 

The semantic model provides a rich vocabulary for use in constructing queries. Therefore, 
users are able to retrieve the same set of information via many channels: 

• by describing attributes and values in technical terms (the traditional way of searching 
for information), 

• by describing the applications at hand in user domain terminology, or 

• by, via indirection, by describing the problem to be solved. 

For example, the following queries could be semantically equivalent in a given data 
source of some domain: 

• a centrifugal pump with bronze casting and propeller, 

• a pump that pumps seawater, or even 

• “we need to pump out seawater” (taking into account the context is in ship design). 
Similarly, users can ask for motors by giving pumps as constraints. 

User-focused query is a key concept in accessing today’s ever-evolving information 
sources. The amount of information and its availability via networks offers great potential 
to leverage the work of others. However, in today’s information systems too many things 
(such as the physical locations of information sources, contents of the sources, 
information formats from the sources and structures of the sources) are changing too 
often and the user is unnecessarily and undesirably exposed to these changes. User- 
focused query provides a solution to overcome this problem. In the Active Catalog 
environment, the user is insulated from unnecessary change by a body of stable domain 
knowledge. A user’s query will have a longer period of persistence or validity in spite of 
changes in the content or even the physical location of the data. 



6 SEARCH ENGINE 

The semantic network is declarative as mentioned previously. The declarative nature is 
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necessary for being able to share the domain knowledge between human users and the 
computer. The semantic model provides a vocabulary that is close to (if not the same as) 
the one employed by the user in daily work and a structure that captures the nature of the 
expert knowledge about the domain. The model explicitly describes attributes, their 
values and their value constraints, as well as the relationships between the objects 
modeled are explicitly. This allows the model be used by a system of reasoning modules 
such as one that automates the translation of a semantic query into corresponding queries 
of physical data repositories. 

Active Catalog uses SIMS (Arens et al. 1993), (being developed at ISI) as its 
knowledge-based search engine. SIMS is an intermediate layer - a mediator - between 
information sources and humans users or applications programs. Queries to SIMS are in a 
uniform language, independent of the distribution of information over sources, of the 
various query languages, the location of sources, etc. SIMS determines which data 
sources to use, how to obtain the desired information, how and where to temporarily store 
and manipulate it, and how to maintain an acceptable level of efficiency in performing its 
task. 

At the top level a query in Active Catalog is translated into a SIMS query using the 
terminology of the semantic network. SIMS converts the initial query into a set of 
semantically-equivalent queries to the physical information sources. SIMS to do this 
needs to know the structure of the information sources and the mapping from semantic 
terminology into physical data sources. The structural information of the data sources can 
be modeled easily (in fact, the major part of the model can be generated automatically by 
querying the schema information of the data sources); the KB-DB mapping at present 
needs to be hand crafted,; better tools are needed here. 

With the three pieces of model, the domain model, the information source schema model, 
and the KB-DB mapping model, SMS performs reasoning on a semantic query (such as 
changing “seawater pump” into “bronze casting material”), partitions a potentially 
complex semantic query into many small pieces and transforms the small pieces into 
actual queries to the physical information sources, taking into account the heterogenous 
and distributed nature of the sources, the efficiency of database joining, parallel accessing 
information sources, and redundant information storage such as mirroring and partial 
overlapping. 



7 INFORMATION CONSUMPTION 

Major effort in Active Catalog has been focused on aiding its users (in the example, 
engineering designers) in evaluating the information returned in response to their 
semantic queries. When a piece of information is retrieved, based on its type, the system 
dispatches the information to an appropriate viewer or consumer. For example, if the 
information is a engineering drawing in AutoCAD (AutoCAD), the system invokes the 
AutoCAD environment and loads the drawing; if the information is a differential equation 
or transfer function described by a MatLab model, MatLab/ SimuLink is brought up with 
the model inserted; if a brochure, the presentation environment is run. 
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In a more sophisticated simulation system, for example, when a piece of information is 
multi-modal, the system separates the total retrieved model object into its constituent 
modalities and then dispatches each piece of the model to its corresponding tool whether 
in a local or distributed environment. 

The use of the system may be illustrated with reference to the example shown in Figure 1. 
As described previously the user queries the system and an appropriate part is returned. 
The object describing the returned part is then examined and the various parts of it sent to 
the appropriate simulator. In the pump/motor example used here, mathematical and 
transfer function simulation models of both pump and motor are sent to MatLab/ 
SimuLink for dynamics analysis while kinematic models for simulation of the pump 
pressure and stroke interactions are sent to WorkingModel. Each system has its own 
display and animation features. 

The working system was implemented on a set of distributed machines using software 
agents running on top of DDE and TCP, and will only be described briefly here. 
Executing the mathematical model in its corresponding environment requires the system 
to automate a sequence of tasks intelligently. The system first sends out a message to a 
Broker (actually running on a different machine to emphasize the distributed nature of the 
work) requesting for MatLab service. The Broker searches its database for pre-registered 
hosts capable of providing the service. The search result, a host candidate meeting the 
specification, is returned to the requesting module that, in turn, contacts the named host 
for service. Upon establishing a connection to the host. Active Catalog sends the 
mathematical model to the server, sets up proper communication channel for data 
exchange between MatLab and WorkingModel and executes the simulation. Thus, the 
models are executed in a distributed environment configured at runtime and hidden from 
the user. 

The user then examines the results, selects other models, other pumps, or motors, or 
combinations of both, until an acceptable design solution is reached. The satisfactory 
parts are then “bought”. Currently we plan to integrate with FAST (FAST), an electronic 
commerce system operating at ISI to implement real purchases. 

The Active Catalog system implements “Try Before You Buy”, a powerful, new 
paradigm of information access. This paradigm, although illustrated here in the domain of 
pump/motor systems, is not limited to this particular domain or solely to engineering 
design. Instead it is applicable to a wide range of applications as diverse as education and 
electronic commerce. 



8 RELATED WORK 

Engineers usually work with catalogs, acquired over the years, that contain descriptions 
of parts and sub-systems. The catalogs form not only the repository of information 
describing the particular part but also form pointers to sources of the part. (An obsolete 
catalog may still be useful in that it points to a source, engineers keep them for this 
reason). Current, up-to-date, catalogs contain descriptions of parts at a detail sufficient 
not only for purchase but also for simulation use . The catalog often contains a picture of 




Active Catalog: a knowledge-rich design library 



169 



the part, a set of descriptors (size, weight, speed and other appropriate specifications, 
drawings etc.). Often included in the catalog is context information... “if you use this part 
you need to buy this widget to make it work’’. Sometimes the catalog contains a short 
technical paper or applications note that tells how the part has been used in a conventional 
or sometimes unconventional manner. Searching for a part is usually a manual operation 
first to find the catalog and a manual operation via the catalog index to then find the part. 
The process could be improved by access to a wider field of information such as that 
provided by the WWW. In addition Active Catalog provides improved tools for 
knowledge based search and dynamically configured simulation both of which add useful 
capability. 

Catalogs are becoming on-line. For example, see the work of and product provided by 
IndustryNet (IndustryNet), PARTNET (PARTNET) et al. Search of these Net-based 
catalogs is mostly by keyword match, with searchable attributes and their values in 
technical terms. Their data can be centralized or federated databases depending on the 
provider. 

AUOTDESK has produced a CD-ROM of drawings of mostly single parts designed in 
their AUTOCAD product that can be down- loaded into a users system for reuse in the 
drawing being produced. 

Logic Modeling Group (LMG), a part of Synopsys, Inc. provides libraries of simulation 
models for VLSI parts. These models work with the major VLSI CAD systems. The 
provision and use of models that can be inserted into CAD systems powerfully improves 
the user’s ability to produce good designs at a faster rate than normd. The design can be 
proven before any component is purchased and often eliminates the need for building 
several sequential physical models. 

Model-based design in the mechanical design domain is rare. Most mechanical “design” 
systems are actually drawing systems. The Active Catalog concept was invented to 
rectify this omission. 



9 FUTURE WORK 

Developing a semantic network that captures the true nature of all objects in the universe 
of engineering design is impossible. It is possible and very desirable to build semantic 
networks for focused domains. This will significantly leverage the ability of designers in 
accessing information. The construction of a close-to-complete semantic model of a 
small domain requires a great amount of effort in knowledge acquisition and engineering. 
The pump network had 300 classes of pumps, 3000 attributes and took three months to 
build. The tools for constructing such networks need improvement but once done, the 
knowledge is expected to last a long time. Cooperative efforts with other groups to build 
and share semantic networks are important. Since Active Catalog has already 
demonstrated the need of such semantic models, we will next test the extensibility of our 
framework by utilizing existing domain knowledge-bases and ontology work from other 
institutes and industry and will focus on middle-ware technology to coordinate and 
reconcile knowledgebases. 
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Our current implementation of the facilitator for simulation-based evaluation relies on a 
body of knowledge about simulation, models, tools, interfaces and data exchange 
protocols. However, the knowledge is implicitly represented by fragments of 
programming code. This will be converted to explicit representations. The need for 
explicitness about servers and their capabilities has already surfaced during server 
selection and in the negotiation and contracting for the WorkingModel and MatLab 
services. 



10 CONCLUSION 

Active Catalog, brings a conceptually new idea to the design domain in the specific 
and to electronic commerce in general. It gives an electronic version of “Try Before You 
Buy” where you “try” in whatever modality is correct for “your” domain. It also supports 
a wide variety of search mechanisms including functional search and supports the use of a 
wide variety of models and modelling systems. The consumption of catalog items in a 
design or modelling environment is predicated on an adequate set of information 
interchange mechanisms. These are provided by agent based communicators. 

Active Catalog facilitates the work of an engineer or other user by using intensive 
knowledge of the domain to enhance the retrieval of useful information more easily, and 
for sifting through the information by using tools, including some for the configuration of 
simulation environments. It contributes to knowledge intensive CAD and benefits general 
information accessing (from retrieval to consumption) in a variety of dimensions: 

• Open-ended and modularized domain knowledge models for ease in bidirectional 
knowledge sharing. As discussed previously, the semantic network in Active 
Catalog gives expanded coverage and enriched detail our current knowledgebase by 
being able to use external plug-in knowledgebases. In turn, its knowledge bases serve 
as stand-alone knowledge modules that can easily be adapted into other 
knowledgebases and semantic networks. 

• High-level, flexible, conceptual queries provide user-focused information retrieval. 

Our knowledge-enabled query allows users to specify needs in a domain vocabulary. 
The query can be partially specified without compromising the capability of retrieving 
the target information; the query can be specified in some cases by describing the 
application and the problem without the needing to know the detailed technical 
terminology. The support of user-focused queries insulates the user from many 
undesirable details such as storage format changes, specific terminology used by 
different pieces of information, and issues of mapping between different terminologies 
and different mental models. 

• Highly automated task environment configuration. Active Catalog currently 
implicitly captures a body of knowledge about tools for information viewing and 
evaluation. This knowledge goes the current capabilities of Web Browsers and uses 
procedural knowledge to configure the distributed simulation environments needed for 
information viewing and evaluation as the need arises. 

• Integrated retrieval and evaluation environment offering a seamless information 
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flow. Active Catalog, using knowledge intensive configuration agents, integrates 
information retrieval and evaluation (as in the simulations described here) as a seamless 
whole, off-loading some distracting time-consuming tasks from the user. 

We believe that an information-rich environment is a necessity for many users in the 
current Information Age and especially for engineers who have advanced demands. 
Information-richness, in itself, may not necessarily, automatically facilitate the work of a 
user; in fact and ironically, many such systems distract the user. The key effort of Active 
Catalog is to provide a set of enabling technologies that allow the future information 
user to focus on the problem to be solved, not on the computing details of how to run the 
models and the environment. 
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Abstract 

The basis of Knowledge Intensive CAD (KIC) is that “intensive life-cycle knowl- 
edge regarding products and design processes must be incoiporated in the center of 
the CAD architecture.” We would like to extend this concept slightly by concentrat- 
ing on the presentation of designs and design information to the designer. In this we 
argue that knowledge about some aspects of the design process must be included in 
the presentation phase of the CAD system. In addition we propose that presenta- 
tion itself is a design process and give a description of this process. 

Keywords 

Presentation, design process, function, style, configuration, display description lan- 
guage. 



1 INTRODUCTION 

The basis of Knowledge Intensive CAD (KIC) is that “intensive life-cycle knowl- 
edge regarding products and design processes must be incorporated in the center of 
the CAD architecture.” We would like to extend this concept slightly by concentrat- 
ing on what might be seen as the ‘edge’ of the CAD architecture, the presentation of 
designs and design information to the user (i.e., to the designer). In this we argue 
that knowledge about some aspects of the design process must be included in the 
presentation phase of the CAD system. In addition we propose that presentation 
itself is a design process. 
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2 THE PROBLEM 

The problem we address is that of automatically generating the presentation of 
some given information about a designed object. In particular we are interested in 
the presentation of information about computer networks. We assume that a presen- 
tation will be instantiated in the form of a display, on a given device. Such a presen- 
tation is very useful for tasks such as network design, network administration and 
network maintenance and service, and a working prototype computer system has 
been implemented [Brown et al 1995] [TENNIS 1995]. 

While this paper uses computer networks as its sample domain, it is easy to see 
many strong correlations with other designed objects, such as mechanical, electrical 
or civil engineering designs. Hence, the issues discussed are quite general. 

Different tasks may require different kinds and amounts of information. Obvi- 
ously for different pieces of information different presentations will be appropriate. 
Also, while different tasks may require the same information, different presenta- 
tions may be adequate for each of them. When generating a presentation the needs 
of the user, general and domain specific human-computer interaction (HCI) princi- 
ples and the capabilities of the device will determine which displays will be appro- 
priate for the presentation and which one of these will the best possible choice. 

As an example let us consider the problem of presenting the down-time cost for 
all the computers in a network. If the user to whom this information is to be pre- 
sented is interested in identifying the computers with the highest down-time costs 
(for instance a network manager), the display to be generated should make this 
identification easy. For this purpose a histogram or a sorted list of down-time costs 
would be good candidates. On the other hand, if instead the user (for instance a ser- 
vice engineer) is interested in topologically or geographically locating the comput- 
ers with high down-time costs, it would be more appropriate to present the values in 
a graph or on a map. 

Further, it is a general principle that a histogram is a better way than a list of val- 
ues to present numeric information that needs to be compared. This principle gives 
a ranking to these alternative presentations. Finally, if the device for which the dis- 
play will be generated only allows alphanumeric output, the histogram alternative 
has to be discarded. 

2.1 Information about computer networks 

One of the factors that determines the kinds of displays and display elements that 
can be used for a certain class of presentation problems is the nature of the informa- 
tion. In the following we give the set of computer networks information types we 
consider for presentation, together with their impact on the presentation needs. 

Structural information 

Structural information about a computer network consists of information about the 
network components (e.g., devices, network components) and about structural rela- 
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tions between components (such as subnetworks, logical and physical connections 
and so on). Network components are typically objects with several attributes, both 
qualitative and quantitative. When presenting information about network compo- 
nents we need means to identify the type and identity of the components as well as a 
way of attaching identifying information about values of their attributes. The pre- 
sentation of structural relations in a computer network may require generic means 
for presenting relations (such as graphs or tables) as well as domain or task specific 
presentation elements (e.g., geographic maps). 

Dependency information 

Parts of a network may depend on other parts of the network while performing their 
tasks. This can be expressed by different types of dependency relations between 
network components. We have identified three types of dependency relations: com- 
munication dependency, service dependency, and task dependency. Since depen- 
dencies are relations their presentation also requires the availability of generic 
means for presenting relations, such as graphs and tables. 

Performance information 

Performance information (e.g., speeds, thruputs) may refer to network components, 
to parts of the network (e.g., a subnetwork) or to the whole network. While gener- 
ally performances are (quantitative or qualitative) measures and, as such, similar in 
nature to attributes the fact that they not only characterize network components, but 
also parts of the network, that may be formed dynamically (e.g., an arbitrary group- 
ing of devices). Hence the presentation of information about them requires means to 
attach measures to the presentation of such entities. For instance, if the problem is 
to present the average CPU utilization for all the computers the names of which 
start with the letter “a”, presentation needs a means for grouping these computers, 
presenting the required information and connecting the two together. 

Maintenance and service information 

We consider maintenance and service information as a separate category for two 
reasons: First its nature may be significantly different from the nature of the other 
information about computer networks (e.g., accessibility information, tool and 
work-force needs, etc.). Second, the tasks for which service and maintenance infor- 
mation is used may also be special (e.g., maintenance planning, human resources 
planning, etc.). 

Some presentation examples 

We conclude this section by giving some presentation examples produced by the 
system we implemented. Figure 1, a and b show the two presentations correspond- 
ing to our example at the beginning of this section. 
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Inspect net_downtime_cost of computers 
produced by AVANTO 




Figure 1(a)* Presentation of downtime costs using a histogram 




Figure l(b).Presentation of downtime costs mapped on the topology of the network 
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Figure 2. presents a more complex example. The goal of the user was to “Inspect all 
the service dependencies of the computer ‘raven’”. From the service dependency 
types considered only two, file service and name service, implied ‘raven’. To clearly 
separate the two types of dependencies two separate displays were produced. These 
were then combined into a page given the need to present them together, resulting 
from the goal. Since dependencies are relations they are represented using graphs. 
The domain preference, to see dependency information related to the network, sug- 
gested the mapping of the graph to the topology graph of the network. 



3 THE PRESENTATION PROCESS 

Using the example in the previous section we can discover some similarity between 
a presentation problem and design problems. Let us explore this similarity in more 
detail. 

The user’s needs (e.g., what the presentation is going to be used for) determine 
the appropriate display alternatives, exactly as design requirements determine the 
solutions to a design problem. Just as these designs are restricted by various con- 
straints (for instance material constraints), the graphical elements and graphical 
properties of the device restrict the set of displays that can be generated. 

Further, a presentation is intended to be used for some given purpose. This use 
assigns a certain role to the presentation, i.e., the corresponding display will fulfill a 
certain function when used. For instance in our previous example of identifying 
computers with high down-time costs, the display will have to relate some values to 
each other, corresponding to the user’s goal of comparing these values. 

Depending on the amount and structure of the underlying information and the 
goal of the user, the function of a display may be simple (such as “to relate” in our 
example) or complex. In the latter case no single display element may be suitable to 
provide the required functionality, and so the function has to be decomposed into 
sub-fimctions (possibly in a recursive manner). For instance, if the function of the 
presentation is to describe a given network, this could be decomposed into showing 
the topology of the network and relating its performance characteristics to average 
performance values of similar networks. Obviously the decomposition itself will 
also depend on the needs of the user. 

Displays can be constructed by combining smaller displays. For instance, dis- 
plays can be grouped together, linked, placed in different relative positions, and so 
on. This is similar to configuration as step of a design process. 

Finally, in order to be generated, displays must have their parameters (e.g., col- 
ors, sizes, distances) set properly, exactly as parameter values must be set in para- 
metric design. 

The above considerations allow us to view presentation problems as design 
problems and as a consequence to model the presentation process as a design pro- 
cess. 

The presentation process has as input a set of requirements. These may be either 
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Inspect all the dependency (ies) of computer ‘raven’ 





Figure 2. Presentation generated for the goal: “Inspect all the dependencies of ‘raven’”. 
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specified (e.g., user goals, current preferences) or implicit (e.g., readability, unambi- 
guity). The output presentation will be a (detailed) description of the display. Since 
the goals of the user constitute one of the most important inputs to the presentation 
process we give a brief discussion about goals in the context of our problem. 

The user’s goals may be described in terms of goal types and goal parameters. 
Goal types specify what the user intends to use the presentation for, while goal 
parameters describe the objects of the presentation. Different goal types may have 
different goal parameters. Some examples of goal types together with their parame- 
ters are: 

• to compare some objects or attribute of objects (e.g., the down-time costs of the 
computers in a network); 

• to analyze a set of information about an object or class of objects (e.g., the 
importance of the devices in a network, based on their dependencies); 

• to identify an object or set of objects satisfying certain conditions (e.g., the com- 
puter with the highest number of file service clients). 

We have already seen that the same information may be presented in different ways. 
One of the most frequent reasons for this is that, even for the same information, dif- 
ferent presentations may be more appropriate for different goals of the user than 
others. (It should be clear that different information may require different presenta- 
tions even if the users goal is the same.) 

3.1 Phases of the presentation process 

Based on the analogy we built between presentation and design we model the pre- 
sentation process as having four phases (Figure 3): function selection and functional 
decomposition (corresponding to functional design), style selection (corresponding 
to conceptual design), display configuration (corresponding to configuration design) 
and parameter selection (corresponding to parametric design). 

We assume that prior knowledge about the design domain (e.g., device taxono- 
mies) and about the design to be presented (e.g., description of the device) is avail- 
able to the presentation process. 

Function selection and functional decomposition 

Function selection and functional decomposition is the first phase of the presenta- 
tion. Its goal is to describe the presentation fimction(s) of the display to be gener- 
ated, such as to show, to illustrate, to suggest, to highlight etc. 

This phase receives as input a description of one or more presentation goals of 
the user. These goals may be of different types, for instance to inspect, to analyze, to 
synthesize, etc. 

The output generated by this phase is a set of partial designs. Each of these is a 
description of what functionality the display to be generated will have. These func- 
tions may be either simple functions (such as “to show a piece of information”) or a 
functional decomposition of a more complex function (such as “relate the degrees 
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Figure 3. Phases of the presentation process 
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Figure 4. Multiple design alternative generation 
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of file service dependencies of the computers in the network”). 

The processing performed is the mapping of each of the user goals in one or 
more presentation functions and, possibly recursively, decomposing these presenta- 
tion functions. This mapping is based on knowledge about tasks & goals of the user 
and knowledge about the domain (e.g., what is the domain-specific for practice pre- 
senting certain kinds of information). 

Style selection 

The goal of style selection is to generate presentation style for the presentation 
functions generated in the previous phase. 

This phase receives as input a set of functional descriptions of the presentation. 
For each of these it generates one or more high level style descriptions. These style 
descriptions may refer to general styles, such as text or graphics, as well as to more 
specific (preconfigured) styles, such as table, bar chart, etc. 

The output of function to style mapping is a set of partial designs, each of which 
is a functional description of the presentation with styles attached to every function 
and subfunction. 

To complete this phase two kinds of processing have to be performed. First, 
functions must be mapped into styles. This mapping may result in a large number of 
different function to style associations for each of the functions and subfunctions. 
Second, the style resulting must be composed in accordance with the presentation 
functions were decomposed into subfunctions (for instance texts and bar charts may 
have to be combined into tables). This step may lead to situations where some style 
alternatives have to be dropped. Dropping alternatives can happen when composing 
two styles makes no sense, when there is no known good way to combine certain 
styles, or when there is some knowledge about the display capabilities of the device 
for which the presentation is produced that makes certain styles and/or style combi- 
nations useless. 

The processing in this phase uses presentation knowledge, based on general HCI 
principles and on domain specific presentation practice, as well as knowledge about 
the user’s goals, expertise and preferences. 

Display configuration 

The display configuration has as its goal to build an overall style for the presenta- 
tion. 

It receives as input a set of partial designs, each of them describing a presenta- 
tion function (decomposition) with a high level style attached. For each of these it 
produces as output of one or more partial designs which contain a detailed descrip- 
tion of the presentation style. This detailed style description is obtained by configur- 
ing the styles in the input, that is building spatial relations among them. 

Thus an element of the output of this phase (a partial design) will be a descrip- 
tion of a presentation function, of the styles attached, and of the relative placement 
of each on the display to be generated (e.g., above, close to, grouped together with. 




182 



Part Three Design Knowledge Representation 



inside, etc.). 

The processing performed consists of building spatial relations from a set of pre- 
defined ones (above, below, close to, etc.) in a way consistent with the goals, func- 
tionality and style of the presentation. This building process uses general HCI 
principles, domain specific presentation practice knowledge, and knowledge about 
user goals, expertise and preferences. 

Parameter selection 

The last phase of presentation generates a detailed description of the display to be 
produced. It receives as input a set of partial designs containing functional descrip- 
tions of the presentation together with detailed style descriptions generated in the 
previous phase. For each of these several detailed display descriptions may be pro- 
duced. These display descriptions include details such as color, size, distance etc. 

The output is produced in a device- and presentation tool-independent display 
description language described in a later section. To produce the detailed display 
description both general and device/tool display knowledge is used. 

3.2 Preferences 

In each of the phases of the presentations several (partial) presentation designs are 
produced (Figure 4.). We call these design alternatives, or simply alternatives. The 
output of the whole presentation process is a single display design, the one which is 
considered to be the best. This process is accomplished by generating a ranking of 
all the display designs produced by the presentation process and selecting the one 
ranked the highest. Using a complete ranking of the display design has the advan- 
tage of providing an “also good alternatives” option to be inspected by the user. 

The ranking of display designs is produced using “preferences”. Preferences are 
classified along two dimensions: scope and duration. We call these dimensions 
types and classes respectively. 

Types of Preferences 

Based on their scope we consider two types of preferences: phase preferences and 
overall preferences. 

Phase preferences are given for each of the phases of the presentation process. 
For each phase the corresponding phase preference gives a set of possible choices 
together with an cM*dering. For example, graphs, tables and lists may be given as 
possible style choices for presenting binary relations and (table, list, graph) may be 
a corresponding ordering. This example of style preference expresses that when 
mapping a function implying the presentation of a binary relation to styles, tables 
will be preferred to lists and lists will be preferred to graphs. 

Overall preferences are given for the whole process of presentation. They 
express the relative importance of the four phases. For instance if style selection 
(such as, deciding on graphics versus text) has to be important the overall prefer- 
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ence for style has to be set high (relative to the other phases). Overall preferences 
are expressed by weights assigned to each of the phases. 

Classes of Preferences 

For duration, preferences may be of three classes: global preferences, user prefer- 
ences and session preferences. Each of these classes may have either or both of the 
two preference types (phase and overall). 

Global preferences express general HCI principles. They are always taken into 
account and are used by default, for situations where preferences of no other class 
are provided. 

User Preferences express overall and/or phase preferences of a user. They are 
part of a user profile. If they are provided, they have priority over global preferences 
(if their use makes sense, that is they produce acceptable partial designs). Also, if 
given, they are used as default in a session performed for the corresponding user if 
no session preferences are provided. 

Session preferences are used to express overall and/or phase preferences for the 
current session with the system. If provided, they override existing user and global 
preferences. 

Using Preferences 

Global preferences are always taken into account by the system. User preferences 
are only considered if the system maintains user profiles (Figure 5.). Neither of 
them changes during one session.Each presentation process uses a set of current 
preferences which are computed from the provided classes of preferences using the 
overriding and default rules described above. The current preferences contain a 
complete set of preferences of both types (overall and phase). 

Applying Phase Preferences 

Phase preferences are applied at the end of each phase, after all the (partial) design 
alternatives have been generated. They are used to compute a score for each of the 
generated alternatives obtained in the corresponding phase. These scores result 
from the ordering specified in the preference for the respective phase and are nor- 
malized in order to give a uniform basis for ranking. 

After all the phases have been completed each of the resulting presentation 
design alternatives have a score assigned for every phase. 

Applying Overall Preferences 

Overall preferences are applied at the end of the presentation process. They are used 
to compute a weighted sum of the scores of phase preferences for every presenta- 
tion design alternative produced. The final scores are used to order the alternatives 
and thus produce a ranking. 

The design with the highest score is considered the best suited for the goal input 
to the presentation process and it is selected for displaying. The ranking can be fe- 
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Figure 6. System structure. 
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ther used to inspect other “relatively good” alternatives. 

3.3 Display description 

As we mentioned earlier the output of the presentation phases is a detailed design 
(i.e. description) of the display. For this purpose we chose to use a display language 
that is powerful enough to describe all the possible displays we generated for our 
problem domain and general enough to be instantiatable in formatting languages of 
general use (e.g., HTML). The decision to use a display language, rather than a 
direct presentation using HTML for instance, was because a display language 
would provide a large degree of display independence. 

In designing the display language, the first major decision was what should be 
explicitly stated and what should be determined by the instantiating process (in our 
implementation the “HTMLizer”). The highest level structure of the display lan- 
guage is the display element. Each display element is an independent single display. 
Each display is composed of one or more “paragraphs”. The language allows for 
some constraint between paragraphs in terms of spatial position. It can be specified 
that paragraphs are near other paragraph or a group of paragraphs should be dis- 
played together. The idea behind these constraints is that in the rendering of the dis- 
play it may be desirable to split a display into several separately displayed units 
based on implementation criteria. 

Each paragraph is either text, a table, a graphic, or a menu. The text and table 
paragraph types are as their names suggest. The menu paragraph type allows the 
HTMLizer to be used as in an interactive mode rather than a strictly display-only 
mode. The graphic paragraph type is further divided into graphs, bar charts, pie 
charts, scatter plots, and network maps. These types were selected based on the pos- 
sible graphics needed for the Tennis system. 

The description of each paragraph has, in general, two major segments: display 
attributes and data. The display attributes are parameters such as size, specific for- 
matting criteria, orientation, and order. The data segment contains the actual data to 
be displayed and any per element display criteria. 



4 IMPLEMENTATION 

We implemented our model of the presentation process as part of our Computer 
Network Ease of service Evaluation System. The presentation part of this system 
was implemented as two communication modules (Figure 6.): the presentation 
module and the post processor (translator/interpreter)module. 

The presentation module is composed of four submodules corresponding to the 
four presentation phases. Each of the modules is built up from a set of rules which 
map the partial designs (or requirements) received as input to new (partial) designs 
produced as output. The rules encode the knowledge used by the respective mod- 
ules. The only type of knowledge that is not represented in the phase modules is the 
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global preferences. The output of the presentation will be a display description rep- 
resented in the display language. 

The post processor module takes as input a display description in the display 
language and translates it to a target language. In our implementation the target lan- 
guage is the HTML. The HTML output of the presentation subsystem can be inter- 
preted by a WWW browser. Our choice of HTML as target language was motivated 
by the followings: hypertext links are fully supported, text formatting is easier, the 
resulting interface is well understood by users and the interface would be available 
to remote sites through the Internet. 

We developed our system while cooperating with network assessment experts. 
For testing we developed a set of test cases for the aspects we were mostly inter- 
ested in, such as: the generation of multiple presentation alternatives, the impact of 
preferences on the choice of the best alternative, and generation of unusual ^splay 
combinations. 



5 RELATED WORK 

Related to our display of results is work associated with the previous phase of the 
TENNIS project [Kemble 1994]. In this work Kemble developed a system for the 
automatic generation of a display based upon the relations inherent in a set of multi- 
attribute data. He used this system to generate displays for both network-related 
information and also classic graphical displays, such as Napoleon’s march. 

Kumar et al [1994] describes work on a user interface for a prototype network 
configuration management system. More generally we found related work on gen- 
eral display techniques. [Weitzman 1992] discusses a knowledge-based graphic 
design assistant for the design of two-dimensional interfaces. Other work we exam- 
ined was [Dewan & Choudhary 1995], [Dourish 1995], [Petre 1995], [Wehrend & 
Lewis 1990]. 

One of the most closely related pieces of work is the SAGE system by Roth at 
Carnegie Mellon University [Roth et al 1994], [Roth & Mattis 1990], [Roth 1995], 
[Chuah et al 1995].They are interested in automating the presentation of informa- 
tion. They confronted many issues we examined, although in a more general infor- 
mation domain than computer networks. Our approach is different from that of 
SAGE in the way it approaches the problem. We view and model the presentation 
problem as a design problem and propose a corresponding solution. 

Another important piece of work was [Chappel & Wlson 1993]. They provide 
general guidelines on appropriate displays for different types of data objects. These 
results were incorporated into the design of the Tennis’95 presentation process. 
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6 CONCLUSIONS 

The system described in this paper is a successful demonstration of our design 
ideas. It is not clear how typical computer networks are with respect to designed 
objects. Some of the problems that may arise with real applications are: a. for the 
generation of actual drawings specialized software may be needed; b. the range of 
goals the system can currently handle is very limited, requiring a more complete 
classification and a more accurate representation of user goals; and c. scaling prob- 
lems may occur due to the complexity of the design to be presented. 

We believe that an important aspect of “KIC systems” will be the knowledge 
intensive computer-aided design of displays of designs and design information. In 
this paper we have presented some general characteristics of such a system, and 
some details of how this can be applied to a particular kind of designed object, the 
computer network. 
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Abstract 

The RACE Asynchronous Collaboration Environment Project (the "RACE" Project) is in 
progress at Research into Artifacts, Center for Engineering (RACE), the University of Tokyo. 
The objective of this project is to find knowledge representation that is useful for the process of 
reorganizing existing information into design knowledge. As a testbed of such knowledge 
representation, an asynchronous and distributed design environment is being built on the basis 
of the World-Wide Web. 
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1 INTRODUCTION 

Identifying requirements and constructing a concept are the most important tasks of the design 
process. Design concept may occur not only on a designer’s desk but in a dialogue between the 
designer and the user, in an advice by a specialist, and in a discussion among designers. 
Computer support is supposed to take a different shape from that of the conventional CAD 
system centered around geometric modeling and analysis. Our concept of knowledge intensive 
CAD is a computer-augmented environment that supports a team of individuals to 
collaboratively create knowledge for design out of the shared information. 

A key to materialize a knowledge intensive design environment is, we believe, the 
representation of design knowledge for synthesis. By design knowledge, we refer to 
information about findings and experiences in the past, which is associated to the current design 
goal. Our hypothesis here is that in contrast with knowledge for analysis that is usually 
represented in the style of classification, knowledge for synthesis rather should be represented 
in the style of association among a collection of information. Figure 1 compares knowledge 
representations for analysis and synthesis. In the process of synthesis, a collection of 
information is incrementadly organized into a consistent explanation of the relationship between 
a set of requirements and a solution. Knowledge representation gives a basis on which 
information is collected and structured. 
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Figure 1 Knowledge representation for analysis in the left and synthesis in the right. 



The view of knowledge for synthesis as associations among pieces of information can be 
extended to the situation of collaborative design. Members of the team provides with 
suggestions and explanations in various perspectives, which are integrated to be a consistent 
body of knowledge about the design solution. To study knowledge representation that is useful 
for collaborative design, we concentrate on the asynchronous mode of collaboration. As Ellis 
argues (Ellis 1991), software for supporting cooperative work can be categorized into modes of 
synchronous or asynchronous in terms of time and centralized or distributed in terms of space 
(Table 1). Video conferencing, for instance, supports synchronous and distributed 
collaboration. Since we are concerned about a team of individuals from different fields working 
together, we are interested in the distributed mode of collaboration. Besides, from a research 
point of view, an advantage of asynchronous collaboration is that exchanged information is 
explicitly represented. Synchronous communication such as a face-to-face meeting and a video 
conferencing conveys implicit information that is hard to capture. To study knowledge 
representation, therefore, we look at the asynchronous collaboration mode. 

Table 1 Collaboration modes. 



space 

time 


centralized 


distributed 


synchronous 


face-to-face 

meeting 


video 

conferencing 


asynchronous 


document 

circulation 


the "RACE" 
project 



As an underlying technology to explore the knowledge representation for synthesis, we use 
the WWW (World-Wide Web). As the WWW is characterized as an embodiment of human 
knowledge (WWW Consortium 1992), it has grown to a huge collection of information. The 
idea of organizing a collection of information for synthesis fits well to the growth of links in the 
Web space. And die feature of the Web that everyone can provide information spontaneously is 
useful for a distributed design environment. 

In the field of groupware (Marca 1992, Palmer 1994) and more recently in the WWW 
community (WWW Consortium 1995), there have been developed a variety of software to 




RACE asynchronous collaboration environment project 



191 



support collaborative work. There is, however, not much research done yet in how shared 
resources are transformed into useful knowledge. We need a closer look at this process to find 
appropriate knowledge representation. 

The objective of the RACE Asynchronous Collaboration Environment project (the “RACE” 
project) is to find knowledge representation that is useful for the synthetic process of 
reorganizing existing information into design knowledge. As a testbed to explore such 
knowledge representation, an asynchronous, distributed collaboration environment is being 
built on die WWW. In the rest of this Chapter, we outline the focused areas of the “RACE” 
project. 



2 OVERVIEW OF THE “RACE” PROJECT 

The evolution of technologies follows a common pattern. We can distinguish three phases of a 
technology life-cycle, i.e., pre-competitive, competitive, and post-competitive phases. In the 
pre-competitive phase, a basic technology spawns out of research. Then the technology is 
applied to new products in the competitive phase, in which the use of technology is learned. 
When the technology is matured, it comes to the post-competitive stage in which knowledge 
about the technology becomes public. The technology as a whole evolves along the iteration of 
the three phases. 

In the transitions of three phases, we can observe the transformation of information. In the 
transition from the post-competitive phase to the pre-competitive phase, knowledge about 
existing artifacts is used for the creation of a new design. In the transition from the pre- 
competitive phase to the competitive phase, knowledge about combination of technologies into 
an integrated product is accumulated. In the transition from competitive to post-competitive 
phases, knowledge about the user of a technology found through the competitive phase is 
retrospectively formalized. Figure 2 depicts reorganization of knowledge along the transitions in 
the three phases. 



competitive phase 



creation of knowledge 
about the use of 
S. technologies 



pre-competitive • • post-competitive 

phase creation of knowledge phase 

about a new technology 

Figure 2 Transformation of knowledge in the transitions of technological phases. 

We look at these phase transitions in the “RACE” project, since reorganization of knowledge 
is distinct. To examine knowledge transformation from the post-competitive to pre-competitive 
phases, we are developing MentS World Browser and Physical World Transmitter. To see the 
transition from the pre-competitive to competitive phases, we are observing a design process of 
a micro mechanism. For the transition from the competitive to post-competitive phases, we are 
building Green Browser. The “RACE” project comprises of the tools developed in these sub- 
programs. 



creation of knowledge 
about the realization 
of technology 
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3 MENTAL WORLD BROWSER AND PHYSICAL WORLD 
TRANSMITTER 

Iterative prototyping is the central activity throughout a design process. The Mental World 
Browser is meant for supporting prototyping in a conceptual world, in the pre-competitive 
phase. The Physical World Transmitter is to be used for prototyping by manipulating shapes in 
a physical world (Kubota 1996). 

MWB-2, running on UNIX workstations, helps the abductive formation of a concept from 
the huge amounts of materials on the WWW. Using an MWB-2 window as a hypothesis work 
space, the user can freely configure objects including keywords and icons, which are linked to 
WWW resources. By hitting an object, MWB-2 will direct the browser to go to the specified a 
WWW resource. Working with the MWB-2, the user cultivates a hypothetical concept in a step- 
by-step fashion. 




Figure 3 MWB-2, MWB2HTML, and MWB2VRML. 

The MWB-2 has been extended so that it can export information from the personal field to the 
public field. MWB2HTML and MWB2VRML have been developed to export data. Figure 3 
depicts HTML and VRML documents, exported from an MWB-2 window. To utilize 
heterogeneous nature of the WWW for supporting collaboration of specialists of different 
fields, we have developed another tool call^ MAC-MWB. A Finder window on the Apple 
Macintosh to the WWW space. As well, we have written Perl scripts called “addwrl/addinline” 
to merge multiple hypothesis spaces using the WWWInline node of VRML. 

The Physical World Transmitter (PWT) in Figure 4 is a combination of a three-dimensional 
laser scanner as the input device and a stereo lithography system as the output device. It is used 
to transfer and reproduce shapes across the Internet. It is an alternative way of traditional 
prototyping using clay models and sketches. MWB and PWT complement each other in 
prototyping the design concept. 
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Figure 4 Physical World Transmitter. 



4 DESIGN OF MICRO ACCELEROMETER 

Design of micromehcanism devices needs various kind of engineering knowledge about 
fabrication, materials, dynamics, electronics, and computer analysis. To examine the process of 
integration of such knowledge in the competitive phase, we have been working on the design 
and manufacturing of a micro accelerometer (Kiriyama 1996). In this design, we try to learn 
what kind of information sharing is useful to support iterative prototyping toward 
materialization. The members of the design team are located at the University of Tokyo and 
Cambridge University. Members at Cambridge University are specialized in micro fabrication 
techniques and design process analysis, and members at the University of Tokyo are 
responsible for computer analysis, the network environment, and micro assembly technology. 

A fabrication test of the micro accelerometer is shown in Figure 5. The technology of focused 
ion-beam cutting is used to make a fine cutting in the bridge between the proof mass and its 
counter part. This configuration, however, does not produce an enough amount of deflection 
for the required resolution. To increase the mass, we decided to integrate the technology of 
micro assembly to bond a proof-mass on the cantilever. 
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Figure 5 Micro accelerometer. 



For finite element analysis of the dynamic and electrostatic behavior of micromechanisms, a 
CAE system has been developed by Yoshimura and his colleges (Lee 1995). The system 
automatically generates finite elements and appropriate analysis conditions, which is then 
passed on to an analysis package. A self-explanatory interface to the WWW for submitting a 
finite element analysis and receiving the result has b^n created using FORM and CGI scripts. 
The interface allows the user to submit an analysis over the network and receive the result. 
Values of resonant frequencies in the result are presented in HTML, and geometric models of 
vibration modes are in VRML. In the interface shown in Figure 6, the user is asked to specify 
dimensions and material properties. 

For information sharing we have used HyperNews, which allows members to post articles in 
HTML. We exchanged information by e-mails and posted relatively fixed results to the 
HyperNews. Another useful way of the HyperNews is to store input models and output results 
of FEM analysis. It allows all members of the team to review the results of analysis. 




jOi|aJ“ [Di^^ 
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Figure 6 Interface for finite element analysis. 
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5 GREEN BROWSER 

Decision making over conflicting requirements is an important activity of synthesis. The 
competitive phase of technology is ftill of such cases, and it is an important source of 
information for post-competitive formalization of design knowledge. The Green Browser 
(Kurakawa 1996) is developed to serve as a tool to model trade-off relationships between 
requirements and decisions made over them. 

As illustrated in Figure 7, the green browser consists of a strategy model, a process model, 
and object models. The strategy model is the central model of die Green Browser, which 
represents requirements for product. The process model represents a product's life cycle, and 
the object models describe the product's attributes. In the strategy model, requirements for the 
product are linked by their relationships of positive, negative, and trade-off. Each of 
requirements and relationships is associated with its description. 




Figure 7 Model of the Green Browser. 



The green browser is built on top of MOO (MUD (Multi User Domain) Object-Oriented). 
MOO Slows multiple users read and write the data. A strategy model is stored in the data space 
of MOO. The MOO we are using has been augmented with an interface to the WWW (Meyer 
1994). A node in the strategy model can be shown as an HTML document and a link is shown 
as liriks between the documents. The network structure of the strategy model can be mapped 
into a three dimensional space and displayed using VRML browsers. By clicking on a node or a 
link, the user can read the document on an HTML browser. Figure 8 depicts a node of the 
strategy model. 






196 



Part Three Design Knowledge Representation 



6 CONCLUSIONS 

In this paper we discussed the concept of the “RACE” project and its components. The 
objective of the project is to understand knowledge representation that is suitable for the 
synthetic process of reorganizing information into design knowledge. To explore it, we focus 
on the technological transitions between pre-competitive, competitive, and post-competitive 
phases. 

Currently, MWB-2 and PWT are used to design a space for thinking and discussion called 
Abduction Machine 1 in collaboration with artists at Wood Studio of the Tokyo National 
University of Fine Arts and Music. The micro mechanism project is in the status of 
experimental fabrication. The Green Browser is under study of effective presentation of the 
strategy model. Future work common among these tools should include quantitative analysis of 
the manipulation of information, as it has been tried on the media of distributed collaboration in 
(Reddy 1995). 
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Abstract 

Effective object-oriented software support of knowledge intensive CAD re- 
quires extension of the object-oriented paradigm because its hierarchies are 
fundamentally based upon ancestral relations. Propagations are proposed as 
an extension to facilitate modeling of interrelationships between features. Such 
object modeling provides an effective software tool for localized perspectives 
upon design knowledge stored in rule and case bases. These local views show 
promise as a means to avoid the combinatorial explosions common to knowl- 
edge based systems, as will be discussed with respect to a completed industrial 
example and to ongoing work on rapid prototyping data. 

Keywords 

Object modeling, knowledge bases, CAD, features, case-based reasoning. 



1 INTRODUCTION: OBJECTS, KNOWLEDGE 

Features are fundamental CAD knowledge representations. Feature-based rules 
and cases can embody semantic design information. It is well known that at- 
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tempting to capture all such knowledge within a monolithic knowledge base 
can lead to combinatorial explosions. 

Providing broadly applicable object-oriented software tools to allow design- 
ers to explicitly represent important semantic information between features is 
the motivation for this work. Our view is that such interrelationships need to 
be supported via a generic software language construct, defined below. 

Definition: A Propagation is a software construct for representing interrela- 
tionships between two non-ancestrally related objects. 

Our work contributes beyond constraints, in its modularity and expressive 
power. Namely, constraints systems frequently permit modeling only within 
a restricted language, having both permitted and prohibited interrelation- 
ships. For example, a geometry constraint system might represent points, 
lines and arcs, with parallelism allowed between two lines, while excluding 
two lines from being simultaneously parallel and perpendicular. In our ap- 
proach to providing modular expressive power, we do not predetermine any 
such restrictions. The user has both more freedom and more responsibility to 
consistently model appropriate interrelationships. To afford such broad flex- 
ibility, we forsake the consistency protections that can be provided within 
specialized domain constraint systems. 

As such, each propagation is an independent, third-party object, and causes 
mediating software to fire whenever a related object is altered. These propaga- 
tions can effect a local partitioning of a knowledge base in that the mediating 
methods associated with a particular propagation could invoke only some 
subset of the design knowledge. 

For instance, a monolithic knowledge base would contain references for 
holes, slots, fillets, bosses, drilling, milling, etc. A significant value of object- 
oriented techniques is the encapsulation of methods within their associated 
objects. Our work extends that metaphor by allowing those methods associ- 
ated with interrelationships between holes to be encapsulated within a propa- 
gation object for holes. This provides the basis for the extraction of the knowl- 
edge about holes from the rest of knowledge base. Thus, access for knowledge 
about holes would need not traverse aspects related to other types. While any 
knowledge base could be so segmented by a knowledge engineer, our software 
environment (ADAM) provides a rigorous methodology to support this pro- 
cess, which, otherwise, might be a tedious, error-prone software development 
exercise. Our efforts so far have concentrated upon prototyping user interac- 
tions and object-oriented extensions necessary to support such modeling. We 
have completed ‘proof of concept’ studies on industrial data with practicing 
engineers to validate that our methodology is supportive of their conceptual 
design process. We report briefly here on that success, while emphasizing its 
role as the first step relative to effective partitioning of large knowledge bases. 

To begin our consideration of such large knowledge bases, we have chosen 
the domain of rapid prototyping. Our reasons for this choice were that the de 
facto standard representation for rapid prototyping (known as the .STL file 
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format), typically has hundreds of thousands of features and that the authors 
are simultaneously developing specialized techniques to consistently maintain 
the conceptual design knowledge implicitly captured within .STL files. 

The remainder of this paper is divided into five sections. In Section 2, related 
work is reviewed. Section 3 describes ADAM. Section 4 discusses a completed 
prototype. Section 5 outlines ongoing work with rapid prototyping data to test 
the ability of these tools to ‘scale up’. Section 6 explores how techniques from 
artificial intelligence can be integrated with propagations. Finally, Section 7 
offers concluding remarks. Biographical sketches of the authors follow. 



2 RELATED WORK 

Our citations to the supporting literature on features and intelligent design 
are admittedly quite terse, so as to focus our emphasis upon the specific new 
issues expressed herein. 

The literature on features is quite voluminous at this juncture in time. 
Hence, there will be no attempt to effectively summarize it here. Rather, 
the reader is referred to a recent monograph (Shah and Mantyla, 1995), a 
comprehensive survey (Shah 1991) and selected papers (De Floriani 1989), 
(Drake and Sela, 1989), (Glovin and Peters 1987), (Gossard, Zuffante, and 
Sakurai 1988), (Gupta, Regli, and Nau 1994), (Henderson 1984), (Hernandez 
et al 1991), (Mantyla, Nau, and Shah 1996), (Requicha 1996), (Rosen 1993), 
(Shah and Rogers 1993), (Vandenbrande and Requicha 1990). Collectively, 
these sources provide a rich set of references for the interested reader. Simi- 
larly, there exists a wealth of literature on applications of artificial intelligence 
to design and we note only those that have most strongly influenced our own 
work (Dixon 1986), (Dixon et al 1987), (Orelup et al 1988), (Hayes and Sun 
1995), and (Prabhakar and Goel 1996). 

The growing recognition of the need to express interrelationships for design 
is expressed in the diverse contexts of chain models (Palmer and Shapiro 
1993) and meta-models (Henderson and Taylor 1993). Also, constraints are 
another form of expression of interrelationships in design (Chen and Hoffmann 
1995), (Dighe, Jakiela, and Wallace 1993), (Fu and de Pennington 1993), and 
(Hoffmann and Juan 1993). 

The distinctive aspect of our research is our focus upon feature interrela- 
tionships as a path towards powerful integration of object-oriented modeling 
and knowledge based support. 
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3 SOFTWARE ENGINEERING: ADAM 

This work has used our software engineering environment, Active Design and 
Analyses Modeling (ADAM) to facilitate our prototyping of non-ancestral 
interrelationships within the object-oriented design paradigm. ADAM is a 
graphic/textually based object-oriented software engineering environment (El 
Guemhioui 1994) and (Ellis 1994). From language-independent designs, ADAM 
can automatically generate code in multiple object-oriented languages, includ- 
ing: C-f-h, Ontos C++, Ada83, Ada95, Eiffel, and a LISP-based dialect. The 
software designer uses ADAM to define object types and to perform analyses 
on the emerging software design. ADAM has been our software engineering 
test-bed for examining the language support issues needed to develop prop- 
agations as a generic design model capability, so as to represent any non- 
ancestral interrelationship between objects. Within this modeling test-bed, 
our CAD test cases have been on industrial examples. 



4 PROOF OF CONCEPT INDUSTRIAL STUDY 

Our proof of concept test part was a disc, with multiple holes (Brett et al 
1996). Our discussion here will focus upon one instance of feature interre- 
lationships. Figure 1 illustrates the propagation entity which enforces the 
minimum spacing between two holes types, the Heel Screw Hole feature and 
the CB Screw Hole feature. 

The radius of either hole is changed by calling a SetRadius method which in 
turn triggers the associated propagation (depicted by a message arrow). The 
propagation then gets the value of the radii of each hole by their respective 
GetRadius methods (depicted by an access arrow). If the new radius does 
not violate the distance test of the propagation, then the radius is set by 
the propagation with a call to its SetRadius method (depicted by a modify 
arrow). This propagation only accesses the design rule for hole spacing, which 
is encapsulated as a method of the propagation object depicted by a circle in 
Figure 1. Rules can be localized to different propagations, thereby partitioning 
the rule base. Such localized views into an industrial knowledge base have been 
advantageous within this prototype. 



5 SCALING UP 

The previous successful industrial experiment was admittedly of modest com- 
plexity and leaves open the issue of applicability to partitioning of large knowl- 
edge bases. Because rapid prototyping is quite data intensive, we look there 
for testing scalability of the interaction of propagations and knowledge bases. 
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Figure 1 ADAM Propagation Entity between CB Screw Hole and Heel Screw 
Hole. 



Propagations are now being investigated in support of design advisors for vir- 
tual prototyping, providing a test of their capability for more data intensive 
environments. These design advisors would have the canonical geometric data 
representation for solid freeform fabrication as their input. This .STL file for- 
mat consists of a triangulation of the boundary surfaces of a solid. Typically, 
there will be hundreds of thousands of triangles, and we consider each such 
triangle to be a feature in this domain. Any geometric design modifications 
can then be accomplished by local changes to these features. 

A fragment of an .STL file is shown in Figure 2. Let p designate the vertex 
common to the 90 degree angles of the black and grey triangles at the center 
of the image of Figure 2. A representative local feature editing could be ac- 
complished by perturbing p, subject to rules to preserve the topological form 
of the artifact (Andersson et al 1994), (Boyer and Stewart 1991), (Boyer and 
Stewart 1992), (Domey 1994), (Peters et al 1996) and (Stewart 1993). 

Rule: For a .STL file, let the parameter u be the minimal separation between 
disjoint pairs of vertices, edges and faces. If for each j and each vertex pj, the 
corresponding perturbation Spj is such that Ppj|| < i^/2, then the perturbed 
object preserves the topological form. 

Each proposed design edit would have an interrelationship to the .STL file, 
as depicted by the propagation testing for topology preservation in Figure 3. 
The disc example had only a modest number of propagations, but a typical 
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.STL file contains hundreds of thousands of vertices, where each such vertex 
might have associated propagations. 




Figure 2 Local View of .STL Geometry 




Figure 3 Topology Propagation 



6 ARTIFICIAL INTELLIGENCE SYNERGY 

To frame critical issues, the following broad research question is posed relative 
to knowledge base partitionings by propagations, as discussed in Section 4. 

• In localizing knowledge within a propagation method, what is the com- 
plementary role of global knowledge relative to logical consistency and 
computational efficiency? 

To explore such issues with realistic test cases, we consider propagations 
for .STL files, requiring the perturbation of many vertices. There could be 
pairwise interrelationships between many of the vertices, as shown abstractly 
in Figure 4. 

Since the geometry of a .STL file is triangulated, design changes which 
would preserve the same topology could be executed by a sequence of pertur- 
bations of individual vertices and adjacent edges, each with its own propaga- 
tion to appropriately limit the vertex movement. If all intended perturbations 
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are less than i//2, then the Rule applies and i/ can be computed once (even, 
off line) and only updated at the end. However, this i//2 upper bound can 
be needlessly conservative. More aggressive edits are possible within specific 
neighborhoods of a vertex and for a particular direction of movement (Dor- 
ney, 1993). However, these more aggressive edits require a propagation of the 
type shown in Figure 3 to fire after each such chosen vertex, requiring an 
incremental updating of the value of u. 

Since the computation of i/ is of quadratic complexity over all disjoint pairs 
of vertices, edges, and faces, it is desirable to see if some of the geometry 
for this quadratic computation can be culled for better performance without 
effecting the validity. This raises more specialized questions within the scope 
of the broad research question articulated, above, namely 

• If the number of such aggressive edits is small, might it be best to do the 
incremental updates without resorting to any culling? Namely, might the 
overhead of culling exceed any over performance advantage gained? 

• If the number of such aggressive edits is large, must the order of their 
execution be considered to optimize the culling and performance. 

The issues of firing a particular propagation then become subject to the ar- 
tificial intelligence concerns typically associated with large rule based systems 
and complex case based reasoning systems. Among them are firing order, effi- 
cient transversal, avoidance of cycles, conflict resolution. Addressing all three 
questions posed in this section will form the basis for our submission to the 
planned 1997 workshop. 




Figure 4 Propagations as Transitive Relationships 



7 CONCLUSIONS 

A prototype of our object-oriented construct of propagations has been em- 
ployed to model interrelationships between features in industrial designs. This 
modeling exercise has demonstrated that this initial prototype of propagations 
holds promise to deliver the following advantages; 
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1. improved abstraction of the conceptual design, capturing the semantic in- 
formation of feature interrelationships, and 

2. local views of knowledge bases to address combinatorial complexity. 
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Abstract 

This paper is concerned with the development of a model for knowledge of consequences 
which can support provident reasoning design. The work is focused on part design synthesis 
decision making so as to support individual designers engaged in life-cycle design exploration. 
The emerging model is one based on structured relationships between a number of aspects 
which are considered to be the source of life-cycle consequences, namely Features [F], 
Parameter values [V], Material [M], Constraints [C] and Process [P] factors. The approach is 
seen to be a framework for the systematization of domain knowledge which can subsequently 
be employed in a Knowledge Intensive CAD system for supporting concurrent design of 
components. Examples in the approach are drawn from the domain of injection moulded 
plastic components. 
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1 INTRODUCTION 

High costs and delays due to problems arising in manufacturing and other life-cycle phases 
from decisions (Andreasen et al. 1990) committed during the design phase is the motivation 
behind the ongoing research programme being reported in this paper. The view taken is that 
these problems are evidence of the difficulty which designers have in taking into consideration 
the life-cycle consequences resulting from their design decisions. There are a number of 
manual and computer based tools which are employed to support particular aspects of life- 
cycle design such as Design For Manufacture (Corbet et al. 1991). These approaches 
however take a narrow view by considering one life-cycle phase at a time, therefore ignoring 
any interactions between the different phases and a late view by being applied after a part has 
been designed and not whilst committing the design decisions. This is in contrast with our 
view of concurrent engineering, based on a definition by (Olesen 1992) who states that 
concurrency requires simultaneity, integration and providence. The approach in this paper 
concentrates on providence, defined as: 

"Providence means to foresee and take into account aspects, which are fixated or 
determined at the design stage" 

This view of concurrent engineering based on providence highlights the need to take into 
consideration the life-cycle consequences and their interactions during the design phase itself. 
Examples from the domain of thermoplastic products presented in this paper reveal that the 
organization and provision of appropriate knowledge can support this life-cycle design 
exploration during design decision-making. Structuring knowledge of life-cycle 
consequences is seen as an essential part of a Knowledge Intensive CAD (KICAD) system 
which supports providence in concurrent engineering. The research objective is therefore one 
of generating a knowledge of consequences model which enables provident reasoning to take 
place during design decision making, so as to infer problem-specific life-cycle consequences 
and their interactions. 

To develop an understanding of providence, the following concepts are used in this paper: 

• synthesis decisions: definition of aspects (add, specify etc.) to the evolving part model, in 
terms of geometric form and physical definitions (e.g. type of material, surface finish etc.); 

• explicit decision: a decision concerning a part feature, attribute or value consciously made 
by the designer; e.g. hole orientation angle = 45°; 

• implicit decision: a decision concerning a part or a life-cycle attribute implied by an 
explicit decision; e.g. use split cavity type mould (because hole orientation angle was 
explicitly defined as 45°); 

• life-cycle phase: a phase through which a component goes during its whole life, namely: 
design, manufacture, assembly, use, service and disposal. Different parts may require 
different processes within life-cycle phases, such as for instance in manufacturing due to 
different materials, surface finish etc.; 

• life-cycle consequences: resulting effects due to committed synthesis decisions, these 
being: 
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• creation of a new decision space in the same or different life-cycle phases; 

• life-cycle behaviour; 

• introduction of new life-cycle constraints because of new decision spaces. 

• performance measures; these are a number of measurable quantities of part performance 
when placed in an environment in a particular life-cycle phase, that are involved in all 
functional areas. They include: design requirement specifications, costs, throughput time, 
quality, efficiency, flexibility, risk and environment. 

• life-cycle behaviour: the behaviour of the part in different life-cycle phases as reflected by 
values of performance measures. 

• constraints: limitations to the independent parameters of a design solution e.g. 
length<2QDmm. 

• independent design parameter: a parameter which can be directly defined by the designer 
e.g. the length of a rectangular plate; on the contrary, dependent parameters such as mass 
are derived from the independent parameters length, breadth, thickness and density. 

• knowledge model: relationships between the design space and the life-cycle behaviour 
space embody what is being termed knowledge of consequences. The description of these 
relationships should provide structure to this knowledge. The knowledge model is 
therefore concerned with what factors should form part of the structure, and with how 
these factors should be organized and related to each other and not with the representation 
formalism. 



2 DESIGN PROBLEM BACKGROUND 



2.1 Dispositional Mechanism 

There are many cases which demonstrate that decisions made during the design phase have an 
effect on different life-cycle phases in terms of performance measures such as cost, time, 
quality etc. As an example, a designer's decision (Figure 1) to define a thermoplastic plate 
with a sharp corner (i.e. radius = 0mm) will influence the type of fabrication methods (in this 
case, spark erosion or cavity construction) that can be eventually used to generate the 
respective mould cavity. This results in an influence on the performance measures cost and 
time of mould construction. A different decision (e.g. radius = 5mm) would result in different 
fabrication methods, such as cavity milling and would have a different effect on cost and time. 
This phenomena termed a dispositional mechanism (Andreasen and Olesen 1990) has been 
employed by (Olesen 1992) to demonstrate that the theory of dispositions can be used by 'the 
designer to foresee and choose the parameters of the product which optimize the conditions 
during production and product life. ’ 
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Figure 1 Typical Decision Consequences. 



2.2 Propagation Effects 

The analysis of a number of thermoplastic part design decision making case-studies resulted in 
evidence that the concept of dispositions can be extended, as the resulting effects of design 
decisions can themselves propagate ftirther onto a number of life-cycle phases, a phenomena 
being termed propagation effect i.e. 

An explicit decision made to achieve an intended effect gives rise to other decisions 
and influences on performance measures in other life-cycle phases. The cumulative 
consequence resulting from the explicit design decision is termed the decision's 
propagation effect. 

For instance, a designer may consciously i.e. explicitly make a decision known to have a 
positive disposition when designing two plastic parts (for some reason each made from a 
different material) in a way which allows them to be ultra-sonically bonded, this schematically 
illustrated in Figure(2). This explicit decision results in a permanent bond and keeps the 
number of parts to a minimum, thereby abiding with a Design For Assembly (DFA) (Corbet, 
Dooner et al. 1991) rule. It also keeps the mould design simple and therefore cheap, compared 
to a snap fit which would introduce mould design and construction complexity and hence 
higher cost. However, what is not evident from this disposition is that if the sub-assembly is to 
satisfy for instance recyclability concerns, then the disposition resulting from the explicit 
decision made by the designer propagates negatively onto the disposal phase's performance 
measures, because it is difficult, time-consuming and expensive to separate permanently 
bonded parts. 
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This example highlights that it is therefore not enough to reveal and control the designer's 
dispositions - rather there is a need to have a wider insight into the interactions between the 
different life-cycle phases resulting from such propagation effects. This problem is the result 
of design methods/tools taking a single, narrow view towards the evolving design solution. 

Thus, designers can be said to be frequently unaware of the life-cycle consequences which 
their explicit decisions propagate, this giving rise to a difficulty in generating design solutions 
satisfying simultaneously the different life-cycle phases. The hypothesis put forward in this 
research programme is that decision-making under such ignorance can be reduced if 
knowledge of life-cycle consequences is made available to support providence during early 
design. The emerging problems to such providence-based design decision making are 
therefore the systematization (Tomiyama et al. 1995) of the appropriate knowledge and then 
its representation in a KICAD system. In summary, the problems identified with respect to 
this research programme are : 

• the traditional design decision making process takes a narrow focus; 

• designers are relatively ignorant of the life-cycle consequences [LCC] they generate; 

• a structure of knowledge is required to support providence which includes simultaneous 
recognition of different life-cycle consequences. 
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Table 1 Limitations To Design Providence 



Design Team 



Virtual Teams 
DFX 



Expert 

Systems 



Constraint 

Networks 

FMEA 



Limitations 

-teams have difficulties in recognizing the complex dispositional effects of 
decisions (Andreasen and Olesen 1990); 

-does not ensure that knowledge about making design decisions and 
compromises will be available (Finger et al. 1989); 

- decisions with potential life-cycle consequences can be committed in the 
interim period between meetings; 

-teams present many logistic, scheduling and other management difficulties 
(Bowen 1995) making providence difficult to achieve; 

-As above except that team members' physical location is not a problem; 
-Time zones between different team members' locations may be a problem. 

- Single view i.e. Interactions/propagation effects not handled 

- Feedback is generic (Molloy et al. 1993) and not problem-specific; 

- employed for design analysis and not for exploration 

- knowledge is not organized in terms of resources which have to be 
coordinated (MacCallum 1991); 

- limited in handling interactions/relationships (MacCallum 1991); 

- narrow domain and hence narrow focus; 

- require a predefined network of parameter relationships (Bowen 1995); 

- design problem has to be expressed as constraints; 

- design modelling not readily associated with decision making process; 

- failure modes are identified late (Norell 1993) the design process; 

- Providence depends on the user's design solution interpretation; 

- single focus at a time i.e. does not handle propagation effects; 



2.3 Current Approaches To Design Providence 

There are a number of approaches that designers use to preview and control life-cycle 
consequences. One approach is through the use of cross-functional design teams (Askin et al. 
1994) to bring all expertise together, and more recently through virtual tiger teams (Cleetus 
1993), which allows geographically separated team members to work together. Although 
design teams and virtual design teams offer a number of advantages to design, they still present 
serious limitations to achieving early design providence, as highlighted in Table 1. Tools of 
the "Design For X" type, essentially offer a checklist (Corbet, Dooner et al. 1991) of do and 
don't guidelines to ensure that a design satisfies the 'X' area. The major limitation with 
respect to providence is that these stand-alone DFX tools are employed as analysis tools when 
as (Gardner et al. 1993) state, major design decisions have already been committed. 
Another approach which can be claimed to support providence is the use of design expert 
systems (Borg et al. 1995). Although expert systems have a predictive modelling power, their 
limitation to design providence is mainly due to the way the knowledge is organized, making it 
difficult to explore trade-offs between life-cycle aspects of an evolving design solution. 
Constraint networks are another type of tool which have been used to assist designers in 
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avoiding the generation of life-cycle problems by supporting cooperation between multiple 
perspectives (Bowen 1995). A limitation of the constraint networks approach is that they 
concentrate on solving a problem expressed as constraints, but do not readily support design 
modelling with its associated decision making process. Another common tool employed to 
avoid potential design solution problems is Failure Modes and Effects Analysis (FMEA) 
(Healey 1994). This and other analysis related tools are essentially employed late in design, 
after major design decisions have already been committed. The limitations of the above 
mentioned approaches are summarized in Table 1. 



3 KNOWLEDGE STRUCTURING 

The approach adopted to modelling knowledge of life-cycle consequences is through the 
structuring of relationships between design decisions and life-cycle behaviour. In this section, 
the structuring framework is presented in a semi-formal way, with relationships for design 
synthesis decisions concerning the addition and definition of features (Wierda 1991) to a part. 
Initially, the work has been focused on components as these are made from a single material. 
Consequently, the examples presented in the following sections will refer to a case study in 
which a hole feature is being added to a plate feature for some desired intent. 

The notation used in the following sections is: 



D 


= 


decision proposal point with a set of options e.g. {add hole? , add ribs?} 


[F] 


= 


part feature eg. hole; 


[Fp] 


= 


feature parameter e.g. the parameter 'depth' of feature hole; 


[V] 


= 


feature parameter value e.g. depth=20mm; 


[M] 


= 


part material e.g. aluminium; 


[P] 


= 


life-cycle process e.g. drilling operation; 


[C]p 


= 


Constraints associated with [P]; 


[dE] 


= 


explicit decision e.g. hole added; 


S 




decision space i.e. set of decisions {what radius?, what 

depth?, what angle?) that have to be all considered i.e. not optional; 


Di 


= 


implicit D 


{DJI 


= 


set of [j] 


- — > 


= 


gives rise 



3.1 Sources of Consequences 

As a result of the identified problems, it is considered necessary to provide designers with 
problem-specific providence, rather than providing designers with generic providence, such as 
in the case with for instance traditional DFX tools. The work has so far identified a number of 
factors, which when structurally related give rise to problem-specific life-cycle consequences 
as will be described in the sections following. 

Feature [F] Factor 
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The addition of a feature to a part introduces a set of feature parameters which require values. 
Each type of feature has its own parameters. For instance, adding a hole to a part will give a 
decision space of {radius?, depth?, angle?}, while the addition of a different feature such as a 
rib will create a decision space {rib height?, rib width? draft angle?}. This means that the 
explicit decision made concerning feature selection is a source of a decision space S. This 
relationship can be described as: 

[d]E{[F]} >S{[F]p} (1) 

read as: 

An explicit decision [d]E concerning the selection of a physical definition such as a 
feature [F], gives rise to a decision space 'S' related to feature parameters [F]p. 



Punch 




(M l = sheet metaL 

• of 'appropriate' launch toot 

• wfflC/iiJJirig of punch tool 

• etc,.. 




upper^plate 

plastic part 
core-pin 



(M |=thermoplastic 

* mmiid tool 

■ shrinkaf^e factors 

* desif^n ofsiihabtecore pin 

* machining of core ‘pin 
‘ formafton of weid-Une 

* Scrap due to welds etc... 



Figure 3 Influence of material [M] factor. 



Material [M] Factor 

On its own, the relationship in (1) is generic and is therefore not sufficient to generate 
problem-specific providence. For instance, the decision add hole can be applied to different 
parts made from a different raw material. Therefore, depending on the material specified (e.g. 
ABS thermoplastic vs sheet metal), the life-cycle consequences will be different (see Figure 3), 
due to the possible processes that can be employed, this relationship being: 

[d]E{ [F] } + [d]E{ [M] } > D,{ [P] } + S{ [F]p } (2) 



read as: 
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An explicitly committed decision concerning a physical definition such as a feature 
i.e. [d]E{[F]}y together with the explicitly committed decision specifying the part 
material [d]E{[M]), give rise to a decision point Di{[P]} concerning possible life- 
cycle processes options together with the feature parameter decision space Sf [F]p }. 

It should be noted that the decision point Dj concerning possible life-cycle processes is 
implicit to the designer and as a matter of fact has traditionally been left to the process planner 
to reveal the relevant set of possible life-cycle processes and select a suitable process. 



Process [P] Factor 

D[P] in relationship (2) reflects the fact that a decision is required. Once the process [P] is 
explicitly selected, traditionally by the process planner after the design solution has been 
generated, then process related constraints which can be influential to the life-cycle 
consequences are introduced. These can be expressed as: 



twist drill 




| M|= t h c r mo piastic: fP)=drilIing ; 



• secondary operaUon intToduced; 

• more time, hwer producthn rate 

• tw *weld tines' formed etc... 

Figure 4 Influence of process [P] factor. 



[d]E{ [P] } -> { [C]p } (3) 

An explicit decision commitment [d]E([P]} resulting in the selection of a process 
results in the introduction of a set of process related constraints {[C]p) influencing 
the definition of feature parameters [F]p, 

For instance, selecting a drilling operation (figure 4) and hence specific drilling machine 
introduces limits on the range of diameters that can be drilled, the tolerances possible etc. On 
the other hand, selecting a different process, such as a laser-drilling, results in a different range 
of diameters that can be drilled. 
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Parameter Value [V] Factor 

Each feature parameter [F]p has an associated set of possible values { [V] } ; for instance, the 
parameter depth for the feature hole has a set of possible values ranging from {0 to thickness 
of part) and the parameter orientation angle has a range from {0 to 360”). Therefore, a 
feature parameter decision space S t.gfangle, depth, radius etc.), requires the consideration 
of a feature parameter (e.g. angle), giving rise to a decision point because a specific value has 
to be specified for that parameter. Hence from (1) this relationship can be expressed as: 

S{ [F]p }— -requires— -> [d]E[F]p gives rise to > D{V) (4) 

The commitment of a value to a parameter from the possible range, together with the 
selection of a process (relationship 3) can give rise to life-cycle consequences [LCC], these 
reflected in the behaviour of performance measures such as cost and time. 

[d]E{[V])+[d]E{[P]) >[LCC] (5) 

read as: 



The committed decisions [d]E{[V]} concerning a value assigned to a feature 
parameter together with the decision committed concerning the selection of a process 
i.e. [d]E{[P]}, can give rise to a number of consequences on performance measures in 
life-cycle phases. 



(a) Vertical Ang le 
O 




Plastic part 



(b) Oblique Ang le 





Plastic part 



* comiJlex mould design & amstructkm 

* higher mould cost 

- longer mould design process 

- longer part -eject Urn etc.. 



Figure 5 Influence of parameter values [V]. 




218 



Part Three Design Knowledge Representation 



The example schematically illustrated in Figure (5) shows how the value of the parameter 
orientation angle 0 of a hole feature, using an injection moulded process [P] effects the 
performance measures, in terms of mould construction time and cost. Cost is influenced 
because the mould ejection system is more complex when con^)ared to a part having a vertical 
hole. This complexity affects the mould design and construction time during the mould design 
stage. It also influences the time taken to eject parts during the injection moulding process. 



3.2 Knowledge Model 

From the relationships established, the knowledge model required for supporting life-cycle 
providence is one organized as schematically illustrated in figure(6). From relationship (2), 
depending on the feature [F] being added to a part and the material [M] chosen, then a set of 
possible processes {[P]} is identified. This means that knowledge for supporting this 
relationship needs to be captured and organized on {[F] and [M]} combinations in order to 
enable designers to become knowledgeable of possible life-cycle processes [P]s that can be 
employed when { [F] and [M] } are being specified. 




Figure 6 Knowledge Organization based on [F], [M] and [P]. 
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Then, the designer can have an insight into possible life-cycle consequences by exploring the 
effect of selecting a specific process [P] from the identified set. For instance, as schematically 
illustrated by shading in Figure (6), the selection of injection moulding as the process for 
generating the hole in the thermoplastic_2 part gives rise to a rationahsed set of knowledge 
concerning that problem specific [F],[M] & [P] combination. Based on relationship [4], this 
set of knowledge, will provide designers with a decision space S ( what diameter, what depth 
etc.) for that feature [F] and a range for each parameter value, constrained by [C]. Hence 
knowledge has to be also modelled on an {[F],[M],[P]} combination basis so as to rationalize 
the knowledge required for providing problem- specific providence. Based on relationship 
(5), depending on the parameter value [V] specified to a feature parameter [F]p, the designer 
can then explore the resulting behaviour of the performance measures in the different hfe-cycle 
phases. 

Each value assigned to the feature parameters will he within a range, for which there is a 
substantial difference in the behaviour of performance measures of the different life-cycle 
phases. This is schematically illustrated in Figure (7), for ranges of the feature parameter 
orientation angle. This means that knowledge on the behaviour of performance measures has 
to be captured and organized on the basis of different parameter value [V] ranges for different 
feature parameters [F]p. 



Example 

Assume that a circular hole feature is being added to a part, made of Thermoplastic_2 
material. From knowledge organized as in Figure(6), the designer becomes aware of a number 
of processes that can be used in this case and opts to explore the consequences of choosing an 
injection moulding process [P], rather than using a drilling or laser process. This combination 
defines the decision space for the hole feature parameters and the range for each parameter, as 
schematically illustrated in Figure (6). Let us assume that the designer is exploring the 
definition of a value to the feature parameter orientation angle. A value of angle=0' lies 
within a range which will for instance result in a set of performance measures for the different 
hfe-cycle phases as illustrated in Table(2). This is derived from knowledge organized as 
schematically illustrated in Figure (7). 

Table 2 - Angle=0" 





Cost 


Time 


Quality 


Manufacturing 


10 


5 


5 


Assembly 


8 


5 


5 


Use 


- 


- 


10 


Service 


7 


12 


20 


Disposal 


7 


12 


- 


Total 


32 


34 


40 



Table Notation: 

higher cost = worse effect, longer time = worse effect; higher quality = better effect 




220 



Part Three Design Knowledge Representation 



The designer may want to explore the alternative consequences on the different life-cycle 
phases by specifying an orientation angle of 45”. From the example provided earlier in 
Figure(5), the performance measure of the different life-cycle phases are affected by such a 
decision, for a number of reasons as stated in Table 3. Tables 2 and 3 give a relative 
indication of the different behaviour of the performance measures for different life-cycle 
phases. For instance, an oblique hole results in a higher manufacturing cost (20) when 
compared to the cost of a vertical hole (10). However, the quality of the part as perceived by 
the client during the ‘Use’ phase has a higher score (40). Besides giving an insight into the 
behaviour of individual life-cycle phases, the overall total of the performance measures will 
give a relative indication of the complete life-cycle effect. For instance, the total life-cycle cost 
for an oblique hole (64) is relatively larger than that of a vertical hole (32) but the overall life- 
cycle quality is better (65). It is such an insight into the behaviour of life-cycle phases that 
enables designers to explore their design synthesis decisions. 




Figure 7 Behaviour of Performance Measures as influenced by values [V]. 
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Table 3 Angle=45° 





Cost 


Time 


Quality 


Manufacturing 


20 (complex mould) 


40 (longer mould design & 
construction + part ejection) 


5 


Assembly 


20 (design, construction of 
special jigs) 


30 (orientation of fastener 
takes longer) 


5 


Use 


- 


- 


40 (happier 
client) 


Service 


14 

(complicated disassembly) 


20 

(takes longer) 


15 


Disposal 


10 (disassembly requires 
more overheads) 


15 

(longer disassembly) 


“ 


Total 


64 


105 


65 



4 ENVISAGED USE OF MODEL FOR DESIGN EXPLORATION 

As explained, life-cycle consequences generated, depend on the combination of the 
commitment of a number of decisions concerning the identified Feature [F], Parameter Values 
[V], Material [M] and Process [P] factors together with the constraints [C] introduced with 
these commitments. These factors correlate with similar characteristics identified by (Tjalve 
1979; Nakazawa 1984; Hubka et al. 1988; Jacobsen 1989) which are however not formally 
related in a way to enable their combination to be employed for design providence during 
decision making. As established, the relationships provide a framework for design synthesis 
decision making which can be supported by the proposed knowledge model. They highlight 
that for life-cycle providence, the design phase is to be considered the phase where to commit 
life-cycle decisions. Such a life-cycle design exploration approach leads to a fundamentally 
different method from for instance one using traditional DFX tools as it supports the 
exploration of consequences whilst the synthesis decisions are being committed. Also, the 
organization of knowledge based on the identified structured relationships provides a wider 
view than DFX - a design for multi-X (DFZX) view. It is envisaged that designers and design 
teams can therefore interact with the proposed knowledge structure as a means of how to 
coordinate their synthesis decision making process in a way which promotes provident 
reasoning. If this is established, the knowledge model is a basis on which to capture and 
organize knowledge for use in a Knowledge Intensive CAD system for concurrent design as: 

• it enables providence to take place during the commitment of design decisions, rather than 
later as with analysis type tools such as FMEA and DFX; 

• it promotes life-cycle design exploration; 

• it identifies the type of knowledge that needs to be captured and how it should be organized 
within a KICAD e.g. combination of [F]&[M] or [F],[M]&[P] etc.; 

• it results in the provision of problem specific providence unlike for example with DFX tools 
because it takes into consideration specific combinations [M],[F],[V] etc.; 

• unlike DFX, it supports multiple life-cycle perspectives, as illustrated in Tables 2 or 3; 

• allows a life-cycle strategy to be considered and committed during design. 
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5 FUTURE DIRECTIONS AND CONCLUSION 

As demonstrated, the proposed knowledge structure supports life-cycle providence during the 
design of components. Work is still taking place to control the scaling up of knowledge for 
realistic design problems through the classification of factors such as processes [P] into 
primary, secondary, finishing etc. Form features [F] currently relate to the manufacturing 
phase, this requiring research to potentially relate them to other life-cycle phases such as 
assembly, disposal etc. Also, the knowledge structure needs to be extended further to support 
feature-feature interactions and to handle situations where knowledge is unavailable. 
Nonetheless, case-studies presented suggest that if the knowledge is vahdated, then the 
amalgamation of a feature-based CAD system together with a computer model of knowledge 
of consequences would be a type of KICAD system which allows life-cycle exploration based 
on providence to be performed during design synthesis. 



6 REFERENCES 

Andreasen, M. M. and Olesen, J. (1990). The Concept of Dispositions. Journal of 
Engineering Design 1(1), 17-36. 

Askin, R. G. and Sodhi, M. (1994) Organization of Teams in Concurrent Engineering, in 
Handbook of Design, Manufacturing and Automation (ed. R. Dorf and A. Kusiak), John 
Wiley & Sons Inc.,. New York. 

Borg, J. and MacCallum, K. J. (1995). A HyperCAD Expert System For Plastic Product 
Design. 3rd International Conference, Computer Integrated Manufacturing, Singapore, 
World Scientific. 

Bowen, J. (1995). Using Dependency Records to generate Design Coordination advice in a 
Constraint-Based Approach to Concurrent Engineering. Co-operation In 
Manufacturing :CIM AT WORK, Kaatsheuvel, The Netherlands, CIMMOD/CIMDEV. 

Cleetus, K. J. (1993) Virtual Team Framework and Support Technology, in Concurrent 
Engineering Tools and Technologies for Mechanical System Design (ed. E. J. Haug), 
Springer- Verlag,. USA. 

Corbet, T., J., Dooner, M., Meleka, J. and Pym, C. (1991). Design For Manufacture - 
Strategies, Principles and Techniques, Addison-Wesley Publishers Ltd.,. England. 

Finger, S. and Dixon, J. R. (1989). A Review of Research in Mechanical Engineering Design. 
Part II Representations, Analysis and Design for the Life Cycle. Research in Engineering 
Design 1, 121-137. 

Gardner, S. and Sheldon (1993). Consensus Statement no. 10.8. WDK Workshop on Design 
For X, Lyngby, Denmark, Technical University of Denmark. 

Healey, J. (1994). Failure Mode and Effects Analysis in Engineering Designer. Journal of The 
Institution of Engineering DesignersfSmJpQh.), A-1. 

Hubka, V. and Eder, E. (1988). Theory of technical systems: A total concept theory for 
engineering design, Springer- Verlag,. Berlin/Heidelberg. 

Jacobsen, K. (1989). The interrelation between product shape, material and production 
method. International Conference on Engineering Design ICED’ 89, Harrogate, 
Mechanical Engineers Publications Ltd. 




Structuring knowledge of life-cycle consequences 



223 



MacCallum, K. J. (1991). Expert System Architecture Requirements For Concurrent Design. 
The World Congress on Expert Systems, Florida, USA. 

MoUoy, E. and Browne, J. (1993) A knowledge-based approach to design for manufature 
using features, in Concurrent Engineering - Contemporary issues and modem design 
tools (ed. H. R. Parsaei and W. G. Sullivan), Chapman & Hall,. London. 

Nakazawa, H. (1984). Information Integration Method. Design and Synthesis, Japan, Elsevier 
Science Publishers B.V. (North-Holland). 

Norell, M. (1993). The Use of DFA, FMEA AND QFD as tools for Concurrent Engineering in 
Product Development Processes. International Conference on Engineering Design 
ICED'93, The Hague. 

Olesen, J. (1992). Concurrent Development in Manufacturing - based on dispositional 
mechanisms/, PhD The Technical University of Denmark,. Lyngby. 

Tjalve, E. (1979). A Short Course in Industrial Design, Newnes-Butterworths,. London. 

Tomiyama, T., Umeda, Y., Ishii, M., Yoshioka, M., et al. (1995). Knowledge systematization 
for a knowledge intensive engineering framework. First IFIP Workshop on Knowledge 
Intensive CAD, Helsinki University of Technology, Espoo, Finland. 

Wierda, L. S. (1991). Linking Design, Process Planning and Cost Information by Feature- 
based Modelling. Journal of Engineering Design 2(1), 3-19. 



7 BIOGRAPHY 

Jonathan Borg graduated in Mechanical Engineering from the University of Malta in 1989, 
after which he worked for 3 years with a Water Authority responsible for CAD systems 
en^)loyed for designing desalination plants. During this period, he also formed part of a team 
responsible in designing and implementing a computer based mathematical model of a water 
aquifer. In 1992 he joined the University of Malta, responsible for lecturing and carrying out 
research in CAD/CAM. In 1993, he graduated with an MSc in Computer Aided Engineering 
Design from the University of Strathclyde, Glasgow, with whom he is currently a PhD 
candidate. He is a member of the Institute of Engineering Designers (UK), the Institute of 
Mechanical Engineers (UK) and the Society of Manufacturing Engineers (USA). 

Professor Ken MacCallum graduated in Naval Architecture from the University of Glasgow, 
and later with a PhD for research into the application of computer graphics to free-form 
surface design from the Imperial College, University of London. After three years with a 
software company, he joined the University of Strathclyde, establishing the CAD Centre in 
1985 as a research and postgraduate centre. Ken MacCallum’s main research area has been 
the application of Artificial Intelligence to Engineering Design. He has led projects concerned 
with intelligent design modelling, data exchange, con^)uter based design coordination, and 
computer aided learning. He is editor of the International Journal on Artificial Intelligence in 
Engineering, a member of IFIP WG5.2, and has been on the Technical Programme 
Committees of a large number of Conferences and Workshops concerned with computer aided 
design. He is currently the Head of Design, Manufacture and Engineering Management 
Department in the Faculty of Engineering, University of Strathclyde. 




14 



Classification of Geometric Design 
Information and Manipulation for 
Vague Geometric Modelling 

X. Guan 

Industrial Systems and Control Ltd 

50 George Street^ Glasgow G1 IQE, UK, Telephone: +^-lJ^l-5531lll. 
Fax: -h44-14i-5531232. emai/; x_guanOisc.eee.strath.ac.uk 

K. J. MacCallum and A. H. B. Duffy 
University of Strathclyde 

CAD Centre, Department of Design, Manufacture and Engineering 
Management, University of Strathclyde, 75 Montrose Street, Glasgow 
G1 IXJ, UK. Telephone: +44^4^5524400. Fax: +44-14U5523148. 
email: kenOcad . strath .ac.uk, alexOcad . strath .ac.uk 



Abstract 

Conventional CAD systems have made significant contributions towards the detailed mod- 
elling and analysis of geometric designs, but axe generally incapable of supporting the 
early conceptualisation and synthesis stages of design. To overcome this weakness, these 
systems need to improve in several areas: (a) they should be able to support designers 
in establishing geometric models using vague geometric information; (b) suitable manip- 
ulations should be available to evolve vague geometric models towards the final definite 
design; and (c) while using the systems, the designers should not need to alter their course 
of design unnecessarily or unnaturally. This paper discusses these key requirements based 
on experience from developing a prototype system for early geometric configuration de- 
sign. Geometric information, manipulations and the corresponding design process are 
examined and classified. Finally, brief description is given on the geometric configuration 
system being developed to explore these requirements. 

Keywords 

Early design support system, vague geometric modelling, computer aided geometric de- 
sign, geometric configuration, CAD 
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1 INTRODUCTION 

Recent studies show that about 85% of the life cycle cost of a product is committed in 
the design process (National Research Council, 1991). Further, 70% of these costs are 
determined early in the course of development when only 3 - 4% of the effort of a project 
hcLS been expended (Andreason and Olesen, 1990). Since they induce cost commitments 
which cannot be changed readily at later detail design stages, early design decisions at 
the concept phase have a laxge effect on the overall success of a product. Therefore the 
rapid capture and evaluation of design concepts which represent the first embodiment of 
these decisions and which caji lead to a reduced design cycle and right first time designs 
is seen as a major goal in design practice. 

For most products geometry is a very important consideration throughout the design 
process, and is a key aspect of the embodiment of new designs. At the early design 
stages, geometric information may mcinifest in various forms, such as shape, size, location 
and orientation. Since precision is not of great concern at these stages, there exists a 
considerable amount of geometric information that is only vaguely known as observable 
from written brief of design concepts, specification and, most obviously and typically, from 
various design sketches (Guan and MacCallum, 1995). Such early expressions of form or 
geometric design contain enough of a designer’s concept to be carried downwards into 
the more detailed geometric definition and specification of the final product. In current 
practice, however, such form concepts are unable to be readily transferred into or directly 
developed in existing CAD systems. More precise and detailed specifications have to be 
developed before the geometric design can be copied into an existing CAD system to 
support a range of downstream activities. An important factor which has inhibited this 
continuous development of geometric design concepts using CAD systems has been the 
gap between the ‘vague’ expressions of form used by designers and the formal and precise 
representations of geometry in the systems. 

The vague expressions of form used by designer are given the term ‘vague geometry’ in 
our work. The focus of our research is thus to seek appropriate computationeil schemes 
which axe compatible with vague geometry. By being compatible with vague geometry, 
the schemes are able to represent and reason about both imprecise and precise geometric 
specification. This makes it possible for the designer to develop the geometric design 
concepts continuously, making commitments based only on what is known or intended. 

One of the key areas of investigation during this research has been the recognition and 
formulation of the essential requirements for the corresponding computational schemes 
or systems. It is our belief that development of a CAD system that supports the early 
stages of geometric design process should be guided by the principles of minimum com- 
mitment modelling and incremental refinement (Guan and MacCallum, 1995), and take 
into consideration the following aspects: 

• the types and characteristics of geometric information used during the design process, 
in particular, at the early stages where designers most frequently carry out ‘back-of- 
the-envelope’ design activities through sketching, 

• the types of manipulation it must provide to support the corresponding design activi- 
ties, and 

• the way the manipulations can be used by the designers. 
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Figure 1 A geometric configuration may have multiple levels of details. 



The key step tciken to gain an in-depth understanding of the geometric information is the 
identification of different types of vagueness and different aspects of geometry to which 
the vagueness can be applied. The result of this, a taxonomy for classifying geometric 
design information, is presented in Section 2. The types of manipulation that the system 
needs to provide are related to the types of geometric design activities conducted. We 
have divided them into three types: synthesis, analysis and re-use. These are discussed in 
more detail in Section 3. The way such manipulations are used should suit the nature of 
geometric design, or design in general. In other words, it should not force the designers to 
change the course of design, or follow a pre-defined sequence, unnecessarily. Requirements 
on this aspect are also discussed in Section 3. Finally, in Section 4, we give a brief account 
of the prototype system through which these requirements are explored. 



2 A TAXONOMY OF VAGUE GEOMETRIC INFORMATION 

Geometric design is regarded as a process of defining the geometric configuration of a 
product. Each configuration may have multiple levels of details (Figure 1), namely, it may 
consist of one or more single, non-decomposable geometric objects (referred to as single 
objects) and/or one or more intermediate geometric configurations (i.e. configurations at 
a lower level of detail). A configuration is defined if and only if all of its constituent single 
objects and/or intermediate configurations are defined. 
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Geometric design information is the set of facts that are specified and used to describe 
or derive the geometric configuration of a product. It can be classified based on the 
type of geometric properties it describes. The geometric properties of a single object 
are classified into its shape and size^ as well as its orientation and location in forming 
the corresponding upper-level geometric configuration. These properties are described by 
geometric parameters. A single object is defined if and only if all of its characterising 
geometric parameters cire uniquely defined. 

A piece of geometric information could also be classified in terms of how vague it de- 
scribes the geometric configuration of the product being designed. Two types of vagueness 
have been identified: 

• incomplete - which refers to the situation where elements of geometry are specified as 
existing either explicitly or implicitly, but values of these elements axe not yet defined 
or known. 

• approximate - which refers to the situation where some piece of information is imprecise 
or uncertain and presents a range of possible choices on the aspects of a geometric 
object. Note that approximation here concerns the definition of the nominal geometry 
of objects. Tolerances related to manufacturing axe not part of the concern. 

Table 1 defines the vaxious combinations admitted by the two view points discussed above, 
i.e. the type of geometric properties described and the characteristic of the description, and 
illustrates them through examples. The classification of a piece of information that gives 
a relative definition of a geometric configuration depends on both the relation and the 
reference object. For example, Hhe shape of object A is the same as that of B’ defines the 
shape of A in relation to that of B. Since the relation - the same as - is precise, therefore 
whether information about the shape of A is incomplete or approximate depends only 
on whether the information on the shape of B is incomplete or approximate. On the 
other hand, ‘the shape of object A is almost the same as that of B’ defines the shape 
of A in terms of that of B through an approximate relation - almost the same as. Thus 
information on A is certainly approximate. But whether it is also incomplete depends on 
whether the information on the shape of B is incomplete. This example also demonstrates 
the possibility that a piece of information can possess a combination of the characteristics 
of vague and definite. 



3 MANIPULATIONS FOR VAGUE GEOMETRIC MODELLING 

A CAD system for supporting the entire process of developing geometric configurations 
of a product should provide utilities that enable or facilitate the use of the various types 
of geometric information classified above in ways suited to the nature of the configuration 
design process. Figure 2 presents a classification of the various types of manipulations or 
utilities envisaged so far for such a system. 

• Synthesis - This type of manipulation can be used to make the geometric configuration 
models of a product. Such a model may be vague initially, but is completely and 
precisely defined at the end of the design process. Consequently, these manipulations 
must support the process of evolving the configuration model from vague to definite. 
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Table 1 Classification of geometric information - definitions and examples. 



Type 




Ch€uracteristic 








complete 


incomplete 


precise 


approximate 


shape 


defn. Shapes with all ele- 
ments given. 


Shapes with missing 
elements. 


Shapes uniquely 
defined. 


Shapes not uniquely 
defined. 




exmp. • Manifold shapes. 

• Shape of A is the same 
as that of B, and shape 
of B completely de- 
fined. 


s Non-manifold shape. 
• Shape of A is the 
same as that of B, 
and shape of B has 
missing elements. 


• Shape of A is a 
cuboid. 

• Shape of B is the 
same as that of 
C, and shape of 
C is a cuboid. 


• Shape of A is roughly a 
cuboid. 

• Shape of B is the same as 
that of C, and shape of C 
is a roughly a cuboid. 

• Shape of D cem be 
any of {cuboid, cylinder, 
sphere}. 


size 


defn . Value of all sise param- 

eters known. 


Not all the sise pa^ 
rameters are given 
values. 


Unique val- 

ues given for sise 
parameters. 


Value of size parameters 
not uniquely defined. 




exmp. • Three sise parameters 
{width, depth, height}, 
all given values. 


• width not given 
value. 


• depth = 20. 

• height = 

depth/2.3A, 
depth = 28. 


• depth » 10. 

• depth = [20,30]. 

• d^th « height X 2. 

• height = depth/2.3A, 
depth » 28. 


orient. 


defn. Value of all orientation 

parameters known. 


Not all orientation 
parameters are given 
values. 


Unique values 
given for orienta- 
tion parameters. 


Values of orientation pa- 
rameters not uniquely 
defined. 




exmp. • Three • angUz not given 

orientation parameters value. 
{anglex,angley, angle z}t 
all given values. 


• angUx = 45®. 


• angUx ^ 45®. 

• angUx = [45®, 50®]. 

• A orthogonal to B. 

• Face 2 of A parallel with 
Face 1 of B. 


location 


defn. Value of all location 
parameters known. 


Not all location pa- 
rameters are given 
values. 


Unique values 
given for loca- 
tion parameters. 


Values of location pa- 
rameters not tmiquely 
defined. 




exmp. • Three location param- 
eters {Xfi,ydtZd}, all 
given values. 


• ya not given value. 


s = 38. 


• ®d « 35. 

• ®d = [34,40]. 

• A above B. 

• Pm-allel ribs should be 
placed at least two rib 
widths apart. 



timnipnlarinn 




Figure 2 Classification of manipulations to be supported by vague geometric modelling 
systems. 
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(a). Skeletonising - an abstraction of an injection moulding part (Chem et al, 1990) 




(b). Simplifying 







(c). Packing 



Figure 3 Generation of geometric abstractions for configuration synthesis. 



Five types of synthesis meuaipulations axe therefore identified: construct which can be 
used to establish a configuration initially, destruct which, destroys a configuration model, 
modify which supports a user to add missing elements to, refine existing element of, 
or remove an existing element from a configuration model, abstract which generates a 
suitable geometric abstraction of a configuration or a part of it to facifitate synthesis (or 
analysis) manipulations, and concretise which, as the counterpart of abstract^ generates 
detailed models from a given abstraction. 

The issue of using abstraction as a tool for simplifying or faciHtating configuration 
synthesis is worth of elaborating upon. Figure 3 illustrates utifities that may be devel- 
oped to form a chosen abstraction of a given geometric model, such as skeletonising 
(a) where medicd axes or surfaces of objects axe generated via fire-propagation or me- 
dial axis transformation (Blum, 1967, Chern et al, 1990, Dutta and Hoffmann, 1990, 
Patrikaleikis and Gursoy, 1990), simplifying (b) where a complex shape is replaced by 
a simpler one such as its bounding box, and packing (c) which generates the geometric 
abstraction of a set of objects by forming or estimating their total or outlining geom- 
etry e.g. by constructing the bounding box enclosing all of the objects. On the other 
hand, synthesis of a geometric configuration may start from an abstract model which 
is then detailed and refined through certain concretisation utilities. 

Analysis - This type of manipulation can be used to analyse a model or part of 
it for the purpose of evaluation or synthesis. Three types are identified: display which 
enables and facilitates the user to inspect and compare developed configuration models. 
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calculate and explain which provides the user with information related to the properties 
of an established model and to the corresponding process. 

• Re-use - This type of manipulation facilitates the recording of generated designs and 
their re-use in new projects or downstream activities. Two types are identified cur- 
rently: record which enables the user to store a developed configuration model into, 
e.g., a library, and retrieve which supports a designer in re-using existing configura- 
tion solutions in synthesising new configuration models. One issue of interest is the 
feasibility of using generalisation in maintaining the library of existing geometric con- 
figurations when new configuration models axe recorded. Generalisation has been used 
in a numerical and object-based design system, NODES, to maintain libraries of design 
concepts (Duffy et al, 1996). The issues here are (a) whether it is useful to make use 
of generalisation similarly in aid of geometric configuration conservation, e.g. to form, 
from concrete and detailed facts about individual configuration design cases, general 
conclusions about the geometry of the type of designs, and (b) how feasible it is to 
develop the required computational mechanisms. 

When using a system equipped with the above types of manipulation, a designer may 
approach a geometric configuration problem in the following ways: 

• Adapting a past solution where the designer searches relevant geometric configu- 
ration libraries for similar configurations developed previously. Once an appropriate 
solution is found, the designer will then select and, if necessary, modify it to suit the 
new problem using the synthesis utilities available in the system. 

• Developing a new solution where the designer makes use of the other resources, 
e.g. generic shape libraries and standard component libraries, and synthesis utilities 
available in the system to develop incrementally and iteratively a new configuration 
for the problem. 

• The combination where the designer may first develop a new vague configuration 
concept from scratch and then for some of the constituent components use geometric 
models available from the geometric configuration libraries and the standard component 
libraries, or vice versa. 

At the end of the design, the designer may decide to store the developed solution in a 
library. Figure 4 illustrates the above process. 

The corresponding support system should facilitate the manipulations described earlier 
to be used during the above process in ways that reflect or accommodate, cls much ets 
possible, three characteristics identified for the process: incremental^ iterative and non- 
sequential (Figure 4). Requirements for the manipulations imposed by each of these char- 
acteristics can be interpreted as follows: 

• Incremental - Use of the manipulations does not demand complete or precise knowl- 
edge or information of a configuration, i.e. bits and pieces of vague or definite infor- 
mation can be used to initialise a configuration model and introduced into the initial 
model gradually when available as design progresses. 

• Iterative - Use of the manipulation should support the modification of emy part of a 
configuration model already defined until it is satisfactory. 
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Figure 4 Geometric configuration design and re-use. 
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• Non-sequential - Use of the manipulations does not require the user to follow a 
specific, fixed or pre-defined sequence. 



4 GEMCON SYSTEM 

Our research into computational schemes for accommodating the requirements discussed 
in this paper has led to the development of a prototype system, GEMCON (an earlier 
version of the system was presented in (Guan and MacCallum, 1995)). The scope of in- 
vestigation so far heis been restricted to simple geometric configuration problems. The 
emphasis has been placed on enabling (a) the use of those types of vague geometric in- 
formation marked in Table 2 by a \/, (b) the utilities for supporting the synthesis of 
configurations as well as display utilities for visual inspection of developed configuration 
models, and (c) the incremental, iterative and non-sequential development of geometric 
configurations. Configuration synthesis manipulations being developed include construc- 
tion, destruction and modification. 

The system is implemented using Harlequin LispWorks (Common Lisp and CLOS) 
running on a Silicon Graphics or Sun Sparc platform. In the following, we briefiy describe 
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the representation and reasoning mechanisms developed and summarise the features of 
the system with respect to the requirements discussed earlier. 

Representation and Reasoning The representation of geometric configurations in 
the system can be viewed as consisting of three parts: geometric structure which provides 
the required elements for representing a geometric configuration consisting of objects at 
different levels of details, parameterised geometric model which provides the parametric 
representation of the geometric properties including shape, size, orientation and location 
of an object, and constraint models which capture geometric design constraints ceirrying 
information that defines the geometric parameters of objects. 

An entity called geom is used to encapsulate the geometric properties of an object. Each 
geom object is allowed to contain other geom objects as its components which may in turn 
contain other geom objects. This results in a tree-like geometric structure and provides 
support for representing a geometric configuration with multiple levels of detcdls. 

The shape of an object may be any primitive - cuboid, frustum, sphere, prism, cylinder 
- whose size is characterised by size parameters such as width, depth, etc. The value of a 
size parameter can be defined approximately or precisely cind is represented by an interval 
which is in turn represented by a lower and an upper bound. The orientation of an object 
is characterised by the rotation of the object with respect to a global co-ordinate system, 
determined by the rotation angles, the co-ordinate axis about which a rotation is Ccurried 
out and the order of rotations about the axes. The location of an object is characterised by 
a datum point chosen as the geometric centre of the object. It lies in a 3D cubic uncertain 
region which captures the approximation or uncertainty associated with the location and 
is represented by three intervals. 

A size constraint model, ein orientation constraint model and a location constraint model 
are associated with each geom object to hold all the constraints specified for ail the geom 
objects contained by the object. These constraints define the values of the corresponding 
geometric parameters. 

The constraint-based mechanism described in (Guan and MacCeillum, 1995) has been 
extended to process size, orientation and location information about a multi-level geomet- 
ric configuration. It includes four stages: update of constraint models which resolves con- 
straints based on certciin defined strategies, updates the corresponding constraint model 
and extracts relevant set of constraints, satisfaction of constraint which satisfies the set 
of constraints extracted in the update stage, update of configuration model which updates 
the relevant parts of a configuration model according to the results derived from the sat- 
isfaction stage, and propagate changes which re-evaluates other pcirts of the configuration 
model affected by the modified part to maintain the global consistency. 

A more detailed account of the representation structure and reasoning mecheinism may 
be found in (Guan et al, 1996). 

Major Features of the System The system is able to model a multi-level geometric 
configuration defined incrementally. As an example. Figure 6 shows a two-level configu- 
ration developed using the system. 

Incomplete geometric information is handled in the system using default values. If 
the shape or size of an object is not specified, then the corresponding default values 
known to the system will be used in establishing an initial geometric model which can 
be modified incrementally and iteratively by the user as information becomes available. 
These default values axe modifiable by the user. The default value of a size parameter is 
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Figure 5 A two-level geometric configuration. 



given a range or an interval of numbers, defined by a lower and an upper bound, instead 
of one single number. K the location of an object is not specified, then the object is 
assumed by the system to be movable in a configuration space associated to the upper- 
level geometric configuration that contains the object. This way of handling incomplete 
information reflects a minimum commitment approach to geometric modelling that has 
been adopted in our work. 

A user can also describe the location of objects in a configuration using approximate 
information such as spatial relations and precise information such as co-ordinates of a 
point. The set of spatial relations currently supported are: above, below, right, left, 
behind, front, above-orth-dist, below-orth-dist, right-orth-dist, left-orth-dist, 
behind-orth-dist, and front-orth-dist, where ‘above-orth-dist’ denotes above with an 
orthogonal distance (the same notation applies to the others). In Figure 5, for example, 
geom2 is above geoml with a given orthogonal distance, while geomS and geomS have an 
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above relation. Again, following the minimum commitment principle, these spatial rela- 
tions are not treated as defining precise point positions for the corresponding geometric 
objects, here geom2 and geomS, but as defining regions of possible positions for the objects. 

Orientation of an object cam be specified through its rotation about the axes of a global 
co-ordinate system. For example, the orientation of geomS in Figure 5 is established by 
specifying a 90® rotation about the Y axis. 

Approximate or precise size information may also be used in establishing the geometric 
model of an object. For instance, size information about a cuboid shaped object - height 
being approximately 15, depth between 20 and 25 and width exactly 30 - can be used 
in establishing the corresponding geometric model of the object through the following 
command: 

(make-geom : shape ’cuboid 

:size ’(((width = 30 )) ((height "= 15 )) ((depth = 20 -> 25 )))) 

The use of the system, therefore, does not demand complete or precise knowledge or in- 
formation of an object. Rather, bits and pieces of vague or precise information can be 
used to initialise a configuration model, which can be built up incrementally. The system 
also supports geometric configuration to be carried out iteratively and in a non-sequenti£il 
manner. It is iterative in the sense that the user can return to a previously defined geo- 
metric object carrying out modifications, non-sequential in that the user can define ciny 
geometric object at any stage. The modelling operations can be invoked in different se- 
quences or orders on different objects. These features of the system are illustrated in 
(Guan et al, 1996) in detail through excunples. 



5 SUMMARY 

In this paper, requirements of CAD systems for supporting the entire geometric design 
process have been examined in terms of the types and characteristics of geometric design 
information used during the design process, in particular, at the early stages, the types of 
manipulation that require to be provided to support the corresponding design activities, 
and the way the manipulations can be used by the designers. Geometric design informa- 
tion and manipulations have been classified. These classifications provide a foundation 
towards the development of vague geometric modelhng systems following the principles 
of minimum commitment and incremental refinement. They may be used, e.g. to guide 
the definition of a representation language supported by the corresponding systems, as a 
framework for assessing the ability of existing systems to support early geometric design, 
and to identify areas of further research. 

A pilot investigation into such a vague geometric modelling system has also been de- 
scribed briefiy. The current implementation of the system has been focused on the con- 
struction, destruction and modification of geometric configuration models based on a 
subset of vague and precise information. Further research is therefore proposed to enable 
the use of the other types of vague geometric information, synthesis and analysis manipu- 
lation described in this paper. Support for the re-use of existing geometric configurations 
also remains as an issue for future investigation. 
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Abstract 

The design of engineering sub-assemblies is an essential and important part of any machine or 
system design activity. These sub-assemblies are a combination of custom designed elements 
and standard components from manufacturers catalogues. This paper describes the way in 
which these elements can considered in an integrated manner at an early stage in the design 
process. This is achieved by the development of an integrated hierarchical structure and the 
parametric representation of catalogue information. 
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1.0 INTRODUCTION 

Engineering products are a combination of systems and sub systems. The function of a 
product is defined as the conversion between the inputs and the outputs of the system and its 
sub-systems [Ullman 1993]. The function of a product describes what must be achieved by 
the design, as opposed to the behaviour which describes how the design performs, although the 
two are often used interchangeably by engineers[Finger and Rinderle,1989] At the heart of any 
system are the multiplicity of individual components that dictate the performance over the 
product life cycle. The authors have identified three types of components, namely 
bespoke(custom) designed components, standard-designed components and standard-selected 
components, which will be described in more detail later in the paper. It is thus essential in any 
knowledge intensive CAD system or functional modelling system that the characteristics of 
individual components are considered. This paper will describe an approach and architecture 
that enables components and their characteristics to be dealt with. 
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2.0 STANDARD COMPONENTS 

Most technical products designed in industry are constructed of a complex hierarchy of 
assemblies, sub-assemblies and components. The definitions of these terms, and the extent to 
which they encompass elements of the product, are held largely in the minds of individual 
designers and are therefore vague and open to interpretation. For example, a vehicle designer 
might consider a car to be an assembly, an axle unit as a sub-assembly, and the wheel bearing 
as a single component within this hierarchy. The bearing designer, however, would consider 
the wheel bearing to be an assembly, the caged elements as a sub-assembly and the inner/outer 
rings, cage and the rolling elements as the components of this assembly. 

In an attempt to rationalise the elements of a product during its design, Hubka[1992] considers 
that a product is a technical system which interacts with other systems and the environment by 
inputs and outputs to the system. To illustrate this, the product shown in Figure l,[Pahl and 
Beitz,1984] is defined by the system boundary S. In addition, further technical systems S1-S5 
represent sub-systems of the product at any particular level of abstraction. Increasing division 
of a system in this way enables the product to be considered at increasing levels of detail, until 
sub-systems are reached which are commonly found in existing machine systems e.g. screws, 
bearings, shafts, levers, wheels etc. These are termed "machine elements" by Hubka, or in this 
paper components. 



S 




S Technical System 

S1 - S5 Sub-systems of S 
11 - 13 Inputs to S 
01 - 02 Outputs from S 
Cl - C4 Comoonents of S2 



Figure 1. Elements of a Technical System(Pahl and Beitz, 1984) 
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This framework does not completely overcome the ambiguities identified earlier, but does 
provide definitions which can be usefully be used namely: 

•A system is a device which converts a set of inputs into a desired set of outputs to carry 
out a specific function. 

•A component is the lowest level of sub-system which is part of a larger system at a 
particular level of refinement of the design. 

Despite their eagerness to advocate their use, most texts and research works do not provide 
much explanation of what is meant by the term standard components. It is generally 
considered that they are components purchased from external manufacturers as '’boughUout 
finished” components, or purchased "off-the-shelf from suppliers[Reinemuth and 
Birkhofer,1993] 

Until now the term standard components has been used to describe a wide range of 
components, obtained from a variety of sources and distinguished by many different 
characteristics. This section will address the lack of accuracy in this definition by proposing a 
classification of engineering components into which standard components can be better 
placed. 

It is proposed that engineering components can be classified according to three primary types. 

1 . Bespoke-Designed Components 

2. Standard-Designed Components 

3. Standard-Selected Components 

And 4 secondary types which overly between these as shown in Figure 2 



Bespoke-l>esigned 

(^mponents 




Figure 2 A classification of engineering components 
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2.1 Bespoke-Designed Components 

If components are not standard, then they are bespoke or custom made. Bespoke-designed 
components are a very wide-range of components which are designed and manufactured to 
satisfy the needs and requirements of unique problems. Other work[Blessing ,1994] has 
shown that as many as 40% of components in a product may be bespoke and therefore cover a 
wide range of types of component. For each component, there is an infinite range of possible 
solutions as, unlike standard components, they are not constrained to conform to a set of 
discrete sizes, except for those imposed by attached standard components. The choice of these 
attaching standard components may therefore have a great influence on the final design of 
large portions of the product and its cost. 

Since they are designed for unique problems, definitive standards and procedures for their 
design may not exist, and they may therefore require a considerable amount of creative design 
and engineering effort to arrive at a possible solution. Typically the design of these 
components may be based on the knowledge and experience built-up by the designer or gained 
from similar previous products. During their design, the unique form of the component may 
be brought about by the complex, multi-flmction and highly-coupled roles that it will perform. 
Due to these levels of complexity, their design may well be carried out using 2D and 3D CAD 
geometric modelling techniques, and analysed using finite element analysis techniques. 

2.2 Standard-Selected Components 

Standard-Selected components are the type of standard component which the designer would 
normally obtain as "bought-out-fmished" from a third-party manufacturer. This type of 
component requires very little creative or intuitive "design" work since they are selected 
according to the selection procedures contained in the supplier's catalogues. Since these 
procedures are defined by individual manufacturers (who may try to preserve commercial 
secrecy) it may be only the selection procedures, and not the fundamental principles on which 
they are based, which are published and made available to the designers. The Author has 
researched the Computer Aided Selection Of Components(CASOC) for a number of 
years[Culley and Webber 1992, Vogwell and Culley 1991, Wood 1994] and shown the various 
problems for the developer and benefits for the engineering designer associated with this type 
of technology 

Nevertheless it is very difficult to establish analytical models for the design of these 
components since these are contained within the selection procedures in the component 
catalogues. Although this is not a problem to the designer who merely selects components 
from the catalogue it does present a difficulty to any system that attempts to make this 
knowledge accessible to the designer in a different way. 
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2.3 Standard-Designed Components 

An additional class of standard components has been identified which are neither bespoke- 
designed nor standard-selected. Standard-designed components are standard components 
which are not generally selected from manufacturer specific catalogues. The design and 
selection of these components is based on well established fundamental principles and 
equations which have themselves become standardised design procedures. The design 
standards which describe the design of these components can be recognised at many levels, 
typically: 

•National and international standards e.g. British Standards (BS), International Standards 
Organisation (ISO), DIN and ASTM etc. 

•Industry based standards e.g. Civil Aviation Authority (CAA), Ministry of Defence 
(MOD) etc. 

•Company based standards e.g. National Coal Board (NCB) and Rover Engineering 
Standards (RES) etc. 

An important characteristic of this type of standard component is that the models of the design 
procedures are not contained within a component catalogue but are well established and 
widely recognised within the engineering community. Therefore these may be published 
elsewhere in design handbooks etc. These standards may contain similar types of procedures 
as those in the suppliers catalogues, i.e. analytical equations, tables, factors and graphs. In 
addition, some may also contain information about preferred sizes, and procedures which 
define how this range of components may be extended whilst maintaining conformance to the 
"standard". This allows a degree of freedom for designers to design and specify standard- 
designed components, outside of the normal range, for particular tasks. 

2.4 Secondary Type Components 

This classification is not rigidly defined by these three primary types of components. Figure 2 
indicates that their is potential overlap between these component types, and it has been 
recognised that many components display characteristics of two or possibly all three of these 
categories. Four types of secondary components have been identified. 

Class A components display characteristics of the standard-designed and standard- selected 
components. These components may be designed to the relevant standards and then selected 
without further analysis from a range of suppliers components which are defined by size and 
form only. Typically this may occur with some of the more common types of gears, such as 
spur gears, which can be purchased "off-the-shelf from suppliers once they have been 
designed. 

Class B components display characteristics of the standard-selected and bespoke- designed 
components. These components may be initially selected from suppliers catalogues in the 
conventional manner and subsequently adapted or modified to the suit the form or function 
requirements of a particular problem. In this instance the component may require further 
specialist analysis to ensure correct function. Typically this may occur with pipework which 
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must be bent or modified and electric motors which require modified flange moimtings to suit 
the product. 

Class C components display characteristics of the standard-designed and bespoke- designed 
components. These components may be designed as bespoke-designed components but some 
elements of it are constrained by standardised design practices. Typically this may occur in 
the design of a bespoke-designed shaft which must adhere to the constraints of a standard- 
designed key-way slot. 

Class D components display characteristics of all types of components. Typically this may 
occur in the design of a particular gear. This may be designed as a standard-designed 
component, selected as an "off-the-shelf component from a supplier and with a machined hub 
to suit the attachment method of an existing bespoke shaft. 



3.0 FUNCTIONAL MODELLING 

Functional modelling is used to represent the functional intent of the product as opposed to 
the geometric intent of the product as performed by the first and second generation CAD 
systems. To achieve this, it is considered that functional modelling can be approached in one 
of two ways [Johnson and Thornton 1991] 

• Quantitatively by considering the mathematical models which link the form of the 
component to its function. 

• Qualitatively by a more philosophical approach which links the form of the component 
to a grammatical description of the required function of the component. 

In both cases, input to the functional model is the required function that the system must 
perform. In the first this may be a numerical description of the required function, e.g. the 
value of the power to be transmitted by a shaft, and in the second a noun-verb description, e.g. 
the function of a bearing is to hold shaft. As Johnson identifies, the second will be the only 
way to design truly original solutions however, despite a number of attempts, the formalisation 
of such a grammar is proving to be very difficult for all but the narrowest of domains 
[Chakrabarti 1991]. 

Since functional modelling has the potential to cover a very wide range of tasks and activities 
in the design process, many researchers have proposed structured approaches for both their 
own programmes and for the wider research community [Duffy and Dixon, 
1990,Ullman, 1992a] to enable more effective research into these types of tools. From these, a 
common consensus has largely been reached which is typified by the taxonomy proposed by 
Finger & Dixon [1989]. This identifies three basic types of design problem and hence three 
general classes of computer-based design tools. 

• Parametric design tools 

• Conftguration design tools 

• Conceptual design tools. 

Many functional modelling tools have been researched and developed within this taxonomy 
and there is an extensive range of research in these areas. This paper is concerned with the use 
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of standard components in functional modelling and one example of this type of work will be 
reviewed. 



3.1 Functional Modelling and Standard components 

The parametric design of simple systems with standard components is reported by Ward & 
Seering [1987]. This describes a system that allows a simple shaft assembly to be represented 
in the computer. By a process of message passing, between the components, and design 
calculations a parametric description of the complete assembly can be made, thus allowing its 
evaluation. Like other systems, the complex process of message passing requires that the 
problem is pre-defined in the computer and prevents the system from being used easily for a 
wide range of problems. 



This problem was recognised by the authors and, in an extension to this work, has been partly 
overcome in the development of the design compiler [Ward and Seering, 1990]. This system 
allows the designer to specify the structure of the design in the computer at the outset of the 
problem. 

This is a good attempt to incorporate standard catalogue components during the design 
process, however, it is limited in a number of ways. Firstly, in order to eliminate the catalogue 
components they must be stored in the computer in a rigid hierarchical structure. This 
prescribes the way in which all manufacturers should organise their product catalogues in the 
future, and does not utilise the CASOC type software which are currently available and being 
developed. And secondly, potential catalogue components are eliminated by excluding those 
which fall outside of the desired parameter range. This requires that all elimination can be 
carried out directly on the data in the catalogue. This therefore limits the potential of the 
approach taken by the design compiler and another must therefore be sought, which is 
described later in this paper. 

Some of the issues mentioned above, regarding the insufficient use of standard components, 
were addressed by Corderoy et al [1991] who propose a system for the conceptual design of 
engineering assemblies. The concept of Computer Integrated Design (CID), as it is known, is 
based on observations about the nature of common mechanical engineering assemblies. This 
recognises that an assembly is constructed of a configuration of many sub-assemblies and 
individual components. To manage the complex interactions of these configurations within 
the complete assembly a hierarchy of control modules is used, shown in Figure 3, which each 
act as a database for the design of a configuration level within the assembly. It is the left hand 
Teg’ of this that the system described in the next section has been developed to address. 

In general, the task of computer-based conceptual design involves the synthesis of functional 
solutions from a functional description of the problem. Since the outcome of this type of tool 
is a function structure suitable for embodiment, it will not involve the use of standard 
components. Any utilisation of standard components will therefore be carried out, at the 
earliest, in the configuration design tools. 
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Figure 3 The concept of computer integrated design 

4.0 MODELLING WITH STANDARD COMPONENTS 

It is clear from the above sections that standard components are an essential element in any 
system and have largely been overlooked in the work on functional modelling. It clearly an 
area of knowledge where engineers need additional support so that they are able to make 
informed decisions about the long term operation of their systems and sub-systems. To address 
these issues the Authors have worked on a systems known as the Bath University Design 
System(BUDS) which has been conceived to address the following issues:- 

• The conceptual design and modelling of engineering assemblies. 

• The incorporation of standard components in the early stages of the design process. 

• The optimisation of engineering assemblies of standard components. 



The philosophy behind the system is to enable the engineering designer to rapidly evaluate 
and develop a concept based on real components, analytical routines and engineering 
standards in an integrated manner, see figure 4. Thus once the concept has been entered 
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into the system and the various operations undertaken the designer would know that prime 
analytical constraints are not violated, standards are satisfied and components that will 
support the loads or transmit the power,etc. are available from manufacturers. The designer 
is then able to optimise the concept before moving into the more detailed embodiment 
stages of the design. To support this aim the system has a number of key attributes as 
follows; 

• Be a user-led aide which will allow designers to make design decisions and 
manipulate the system to their own requirements. 

• Allow data to be entered, used and modified in a common format. 

• Specify a minimum amount of data to define a design problem. 

• Present a graphical representation of the problem or solution to the designer. 

• Provide appropriate help facilities and intelligent feedback to the designer. 



4.1 The Bath University Design System (BUDS) -Overview 



BUDS has been developed as a computer-based support tool for the adaptive design of 
engineering systems at the conceptual and embodiment stages of design. An overview of the 
system is shown in Figure 4. Once this concept variant has been represented in the system, a 
range of tools enable this concept to be: Designed, analysed, evaluated and refined for 
functional suitability using the Parametric Design Algorithms, optimised using the General 
Purpose Optimisation System, Embodied with suitable standard components using the Detail 
Specification Tools. 





Figure 4. Overview of the Bath University Design system (BUDS) 
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This process progresses an initial concept variant to a part-embodied design solution. The 
result of these phases is a functionally and dimensionally optimised conceptual layout of the 
design. Standard components are considered in two ways as follows 

First-stage - Parametric Desig n Al gorithms 

During the conceptual design phase a Parametric Design Algorithm (PDA) is used to carry out 
the preliminary design, analysis and evaluation of the functional suitability for all sub-systems, 
components and features in the concept. This is done to ensure that the complete system is 
able to fulfil the overall function defined by the designer. 

Secmd - Mage - Detail Spec ific a tion ToqIjs 

The second-stage for incorporating standard components is by their detailed selection and 
specification using Detail Specification Tools (DSTs). These are third-party CASOC-type 
component selection packages which are used to select real components from the output of the 
PDAs. 



4.1.1 Design Optimisation 

It has been proposed [Theobald et al.,1993] that the optimisation of a design model that is 
developed using BUDS is carried out using a three-stage strategy which is shown in Figure 5. 
These are summarised here for completeness but are outside the intended scope of this paper. 

First-stage - Corfiguration Optimisation 

This is carried out to develop the optimum function structure and configuration of components 
to satisfy the overall flmction of the system. At present this is a manual process carried out by 
the designer who decides the layout of the concept and the types of component which satisfy 
the solution principles 

Second-stage - Parametric Optimisation 

Once a suitable configuration of the concept has been established, this process is used to 
optimise the variable functional and dimensional parameters of the overall system and its 
components. This is done before the detailed selection of the standard components using the 
Detail Specification Tools is carried out. 

Third-stage - Relational OptimisatiQn 

After selecting and specifying a range of suitable components using the Detail Specification 
Tools, this process is used to optimise the combination of these. 
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Figure 5 Stages of optimisation. 

4.2 The Architecture of BUDS 

The system architecture of BUDS is shown in Figure 6. It consists of 5 main software 
modules. 

• The Model Builder - This is the main user interface for the system, where the designer is 
able to represent the concept model of the design using the icons in the toolbox, and can 
initiate control of the system. 

• BudsCore - This is the main control system for BUDS. It is also the main database 
which stores the concept design model using an object-oriented approach. This is 
described in more detail in the next Section. 

• The Parametric Design Algorithm Library (PEDAL) - This is contains the Parametric 
Design Algorithms for each type of component that can be used in the modelling 
system. 

• The General Purpose Optimisation System (GPOS) - This is an independent 
optimisation system which can be linked to BUDS when optimisation is required. 

• The Detail Specification Tools (DST's) - These are a range of third-party software 
packages which are used for the detailed selection and specification of standard 
components. 
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Figure 6 Architecture of BUDS 

4.3 Parametric Design Algorithms (PDA) for standard components 

It is suggested in models of the design process [Pahl and Beitz,1984, Ullman, 1992b] that 
during the early development of a conceptual design, the designer carries out a number of tasks 
to evaluate the initial suitability and feasibility of a proposed solution. These decisions are 
generally based on quick and rough design calculations based on well known and widely used 
principles. These are often used to determine the major functionally important parameters 
which are used to evaluate the design. For example, in the conceptual design of an engine 
con-rod the designer may make rough calculations to determine the buckling limit of the 
connecting web based on approximate known dimensions. This will be done to evaluate the 
feasibility of the functional parameters of the engine such as the maximum power and torque 
output. 

This activity is carried out in the BUDS design process using the Parametric Design 
Algorithms (PDAs). These are essentially software-based representations of the conceptual 
model for each type of component within the design domain. A PDA is required for all types 
of engineering components, namely bespoke-designed, standard-selected and standard- 
designed components. It is proposed that it is at this stage when standard components should 
first be considered as elements of the BUDS design model. 

It was suggested by Hoover et al.[1991] that an engineering model is used for two purposes: 
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•To enable the design to be refined to a more complete state. 

•As a means of predicting the behaviour of the system. 

These are tv^o of the tasks that are carried out by the PDA. In the PDA, these are referred to as 
the design and analysis functions respectively. In addition, the PDA is also required to carry 
out a third function. This is to evaluate the feasibility and suitability of the component to meet 
its required function. It is important to differentiate between these tasks of design, analysis 
and evaluation in the PDA. 

4.3.1 PDA Design 

This is the task of estimating and proposing the form, dimensions and other physical attributes 
of a component to fulfil the functional requirements, and hence refine the component from an 
abstract state to a more defined one. This information is required for three reasons: 

• It enables a minimum amount of information to be proposed and entered about a design 
during the conceptual stage. 

• It creates information which may be necessary for the subsequent analysis and 
evaluation tasks of the PDA. 

• It creates information which is necessary for the subsequent optimisation and detailed 
specification of components . 

4.3.2 PDA Analysis 

This is the task of examining the functional behaviour of the component based on its physical 
description. Obviously, analysis of the component cannot be carried out until some element of 
design has been carried out to determine its physical description, whether speculatively by the 
designer, by the design element of the PDA, or by constraints imposed by surrounding 
components of the design model. 

4.3.3 PDA Evaluation 

This is the procedure for making reasoned decisions, based on the form and functional 
attributes determined above, about the suitability of the component for the task. These will be 
based on the constraints applied by the PDA, the other components within the system and the 
requirements specified by the designer. In the case of unsuitability, feedback should be 
provided to the designer in two ways. By setting the appropriate traffic light of the component 
in the design model, and advising the designer on the nature of the constraint violation and 
suggesting ways of how this conflict can be resolved. 

4.4 The Resolve Process 

The Resolve Process is the way in which the system uses the PDAs for the design of each 
component in a BUDS model. The resolve process is initiated by the designer once the 
concept design has been modelled and the requirements and constraints about the model have 
been defined. The way in which this process is managed must address the following issues. 

•How do the requirements and constraints get propagated through the model ? 
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•How are conflicts between different constraints managed ? 

•How is it ensured that each component PDA is executed properly? 

The outcome of the investigation is a process which manages these addresses these issues. 
This is referred to as the Resolve Process which consists of three main tasks: Data 
Propagation, Data Arbitration and PDA Execution. 

4.4.1 Data Propagation 

The data propagation process ensures that the requirements and constraints defined by the 
designer, optimisation system and the PDAs of the components are propagated to all other 
components of the model that require them. This process considers each component of the 
model in turn and, using a variation of the blackboard principle[Engelmore and Morgan, 1988] 
collates and redistributes the required component parameters. To ensure propagation 
throughout the complete BUDS model a three-step operation is used. 

• Step 1 - The data is propagated up and down the vertical component "chains". 

• Step 2 - The data is propagated across the horizontal "nodal" components. 

• Step 3 - The data is re-propagated up and down the vertical component "chains". 

Information about which component parameters are to be propagated are defined in the generic 
class definition for the component object. This defines which parameters are to be input and 
which parameters are to be output for each class of component. For example, in a shaft key 
component object , the shaft diameter, hub length, power transmitted and shaft speed are input 
and key cross section , key length and key mass/cost are output for each instance of a shaft 
key. 

4.4.2 Data Arbitration 

Data arbitration is required to resolve the conflicts encountered during data propagation. This 
is necessary to ensure that less important requirements and constraints on the system (e.g. 
default values) do not overwrite more important ones (e.g. values entered by the designer). 
During data arbitration the following hierarchy of constraints is used: 

• Designer entered parameter. 

• Optimised parameter. 

• PDA calculated parameter. 

• Default parameter. 

During data propagation, if the blackboard encounters two conflicting parameters the 
arbitration process uses this order to ensure that the more important value is maintained by 
either overwriting, or not propagating, a less important parameter. If two equal status 
parameters are encountered the conflict is brought to the attention of the designer to resolve. 

4.4.3 PDA Execution 

After the data has been propagated and arbitrated for the complete model, the PDA for each 
component is executed. This is only carried out if the attribute parameters have been changed 
after the data propagation process and consequently the traffic light is in the intermediate 
amber state. 
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The complete Resolve Process requires the propagate-arbitrate-execute cycle to be carried out 
twice. This ensures that the components parameters calculated during the first pass are used as 
constraints for the other components in the second pass. At the end of this second pass the 
feasibility of the model can be assessed from the status of the traffic lights on each component; 
if all traffic lights are green then the model is feasible. 

4.5 The Detail Specification Tools (DST) 

The second-stage of the strategy for incorporating standard components is using the Detail 
Specification Tools (DSTs). These are third-party software applications which are used for the 
detail design, analysis or catalogue selection of the components. 

The detailed design of the components can be carried out after a feasible parametric model is 
obtained regardless of whether the design has been parametrically optimised or not. 

5.0 MODELLING POWER TRANSMISSION SYSTEMS 

The previous Section has described the generic BUDS system. It was required that the system 
should be used for the design of a wide range of engineering systems, and the construction of 
the system allows for this. However, for the implementation of a prototype system it has been 
configured for the design of rotating power-transmission systems. This is particularly relevant 
as items such as bearings, gears and belts have a lot of attributes associated with them and 
have key life equations for example. 

5.1 The Design of Power-Transmission Systems 

The development of computer-based tools for the design of rotating power- transmission 
systems has been the subject of other research works [Claypole, 1993, Howe et al.l986]. 
However, these are limited in their ability to model the systems in a flexible and effective way. 
Two major problems have been identified. Firstly, there is a lack of flexibility in the 
configuration of a design problem. For these systems, the configuration is effectively hard- 
coded into the modelling system. Attempting to explore alternative concept configurations 
quickly and easily would require extensive re-writing of the system. Secondly, in many 
systems small yet important elements of a power-transmission system are neglected, such as 
elements which connect components onto the shaft, and connections with the external 
influences of the system. It is perceived that this is because of a lack of structure to the 
configurations. It is these important aspects that need to be addressed for more knowledge 
intensive support for engineering designers. 

5.2 Power-Transmission Component Hierarchy 

Observation of the power-transmission domain reveals a structure which is common to many 
systems. A more complete structure consists of five elements described below. 

• Global element - This defines the engineering domain which is being considered. In 
this case, it is a power transmission system domain. This element should contain the 
global attributes and ftmction of the system. 
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• Nodal element - This element defines the structure of the global system and how it is 
decomposed into the configuration of elements. In this case, it describes the basic 
construction of the shaft into shaft nodes. 

• Auxiliary element - This element characterises the connection between the application 
elements and the structure of the system, i.e. the nodal elements. 

• Application element - This element is the primary functional element of the system. In 
this case, it is the components which transmit power, resist loads etc. 

• External element - This element is the interface between the system and the 
environment in which the system is contained. 



5.2.1 The BUDS Power-Transmission Domain 

For the purposes of this research the prototype system has been populated with the following 
power-transmission components, features and sub-systems: 

• Global element - shaft 

• Nodal element - shaft node 

• Auxiliary elements - shaft key and free-fit 

• Application elements - generic bearing, deep groove bearing, angular contact bearing, 
generic power-transmission element, gear-pair sub-system, tooth-belt sub-system and 
an inertial load. 

• External elements - input, output and bearing mountings. 

Parametric Design Algorithms have been developed for each of these classes of components. 

5.3 Power Transmission Example - The Oil Burner Shaft 

The example in Figure 7 demonstrates how the concept for an oil burner shaft can be modelled 
by decomposing the problem into a six-node configuration. These are represented by shaft 
nodes and the following components: the oil atomiser and fan as rotating loads which consume 
power, the two bearings which are attached to the shaft node by a free-fit and are mounted to 
the surroundings, the keyed-on gear which drives the oil pump, and the keyed-on toothed-belt 
which transmits power to the system from the electric motor. 

This example illustrates that in some situations the component hierarchy is not completely 
satisfactory since the oil atomiser, which is manufactured as an integral part of the shaft, does 
not require an auxiliary component to attach it to the shaft. In this case, the component is left 
as a null component from the initial template. 
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Figure 7 Power Transmission Example- An oil burner shaft. 



6.0 CONCLUSIONS 

It is clear that standard components of whatever description are essential ingredients of any 
engineering system, their choice and design will have profound implications for the long term 
performance of any machine or device. It is therefore essential that they are considered as 
earlier as possible in the design process and are considered in conjunction with ethe rest of the 
system and not in isolation. 

Thus this paper describes a strategy for incorporating standard components into a computer 
aided design system, which has been implemented. This has been achieved using a two-stage 
approach. The Parametric Design Algorithms are used for the initial functional modelling and 
evaluation, and the Detail Specification Tools are used for the final selection of actual 
components. The system allows the designer to input a minimum amount of data which is then 
propagated through the system. It also allows constraints and conflicts to be addressed and a 
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preliminary viable functional model, including the availability of suitable standard 
components, to be achieved. 

The modelling system has been configured in its prototype form for the design of power- 
transmission systems. This has enabled a number of standard component models to be 
usefully used for the conceptual design of a wide variety of systems. 

With this structure it is considered that additional domain knowledge, operating performance, 
actual life cycle performance data can readily be incorporated so that these additional 
considerations are considered as early as possible. 
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Abstract 

While concurrent engineering has become an accepted philosophy, its implementation leads to 
a need for radically different software support tools than those that are currently in the 
marketplace. This paper discusses the requirements for such tools, with emphasis on providing 
support in design for manufacture. The paper highlights recent progress in providing data 
driven design for manufacture support for injection moulded products based on the use of both 
Product and Manufacturing Models. This concept is then used to explore ideas which have the 
potential to provide design support where multiple manufacturing processes impinge on design 
decisions. The use of product range models, multiple view representations of product data and 
data interpretation mechanisms to release manufacturing information are discussed. 

Keywords 

Design for manufacture, product models, manufacturing models, information sharing. 



1 INTRODUCTION 

Providing designers with high quality information on which to base decisions is central to 
achieving good results. Although people are generally good at innovation in design and in the 
evolution of new design ideas they are not good at managing and remembering the many 
complex pieces of information which impinge on design decisions. The ideas presented in this 
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paper have their emphasis in the provision of information support. This is believed to be a 
critical area of research if future Computer Aided Engineering systems are to provide an 
adequate support for design in a concurrent engineering environment. 

While a range of work has addressed design for manufacture for single processes, this paper 
discusses research into software tools which can support design for manufacture where a 
number of manufacturing processes impinge on the design. The focus for the paper is the 
design of high volume customised products with particular emphasis in the area of net shaped 
products such as injection moulded products. Existing commercial tools which are offered in 
this area are typically based on post design analysis of finite element models. These are 
inappropriate for concurrent, multi-process, design for manufacture. Other research related to 
design for manufacture for injection moulding (Hanada, 1989) highlights the potential of multi- 
process design for manufacture in this application area. 

Recent research in collaborative CAD environments for architectural design has identified the 
need for several models of a design object to support multi-disciplinary design (Rosenman & 
Gero, 1996). Other work fi-om the same laboratory (Saad & Maher, 1996) has highlighted the 
need for a shared underlying representation which can support collaborative design. While their 
work focuses on multi-user environments, this paper argues a similar need for shared data 
representations to support design for multi-process manufacture. 

It is argued that future design for manufacture support systems will comprise the following 
parts which require further investigation and research: 

(a) Manufacturing information representations. 

(b) Product data representations for multiple manufacturing viewpoints. 

(c) Interpretation mechanisms between these viewpoints. 

(d) Local strategists to act on the range of product and manufacturing information. 

(e) Interaction mechanisms between design for function and design for manufacture which is 
some cases can be supported by Product Range Models. 

2 INFORMATION MODELS TO SUPPORT DESIGN FOR MANUFACTURE 

An important aspect of the approach described here is that it utilises the product model 
concept as a basis for data integration and data sharing. The paper builds on earlier work on 
information sharing in design and manufacture (Ellis et al, 1995) which explored the MOSES 
concept illustrated in figure 1. This work on Model Oriented Simultaneous Engineering 
Systems (MOSES) showed that two information models, one capturing product data and one 
capturing manufacturing process data, can be used to support product life cycle decision 
making. The approach taken is based on the use of object oriented databases providing 
supporting information to appropriate design support tools. 
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Figure 1 The MOSES Concept. 



Progress is being made in understanding how product data can and should be represented to 
provide interchange standards between computer aided design systems through the work of 
STEP. Further, such product models have been shown to provide a successful route to the 
integration of a range of design and manufacturing software (Corrigall et al, 1992). Whilst the 
modelling of such product information is fundamental to the provision of information support 
for design, there is the need for a second model which can provide a representation of 
manufacturing capability and resource information. This is termed a Manufacturing Model and 
provides a source of manufacturing knowledge to support design and manufacturing decision 
making (Al-Ashaab 1994, Molina 1995). 

The combined use of product and manufacturing models has the potential to provide the 
necessary information to support the full range of applications in product design and 
manufacture. This approach provides a highly flexible and extendible method of constructing 
CAE systems, enabling companies to capture their information assets within the data models 
and link these to the most appropriate third party software solutions available at any point in 
time. 



3 A DESIGN FOR MANUFACTURE APPLICATION ENVIRONMENT 

In an information supported system all software applications must rely on the information 
models as their source of information and as their output repository for information which may 
be used by designers or other applications. Once a Manufacturing Model has been defined a 
key requirement for any software support application is to be able to provide information 
inputs in a suitable form to access and use each type of information in the Manufacturing 
Model. Applications should also support the concurrent engineering philosophy and therefore 
must be active as early as possible in the product life cycle. 
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Figure 2 The PT-Plus Case Study. 

Our work on injection moulding has shown that a design for manufacture software support 
system, termed an injection moulding strategist, can provide design support by utilising 
information held in both a product model and a manufacturing model (Al-Ashaab 1994, Lee, 
1996). A particular product case study, called PT-Plus, which is a tamper evident ring used in 
food packaging, has been used in exploring the research ideas, as shown in figure 2, and is 
used here to take these ideas further. 

Knowledge about the injection moulding process has been stored in a manufacturing model 
and the requirements for the product have been captured in a product model as have alternative 
possible ways of meeting these requirements. An injection moulding strategist has been 
configured to provide the product designer with support to design both the product and the 
mould concurrently. Taking this approach it has been possible to provide advice to designers 
both on the design for manufacture of a product and the design of the mould needed to 
manufacture the product. 
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The strategist has been found to perform three key roles as illustrated in figure 2; 

(a) to provide a structure against which concurrent interactions can take place; 

(b) to capture the manufacturing strategy to be applied at each stage of the design for 
manufacture process; 

(c) to provide the translation mechanisms which enables the product design data to be 
converted into the forms needed by the various classes of information contained in the 
manufacturing model. 

4 DESIGN FOR FUNCTION AND DESIGN FOR MANUFACTURE 
INTERACTIONS. 

The structure of the injection moulding strategist allows design for manufacture support to 
take place effectively. However, there is also a need to link to the functional requirements of 
the product if there is to be any concurrent interaction between design for function and design 
for manufacture. This leads into a critical problem of how to provide an environment which 
can allow designers to work with the fimctional needs of a product while still offering back 
advice on manufacture. This is recognised in the features community as a major problem 
requiring novel solutions (Allada and Anand, 1995). 

It is possible, in high volume customised products, like the PT-Plus example, that the use of 
fimctional features, supported by a database containing knowledge of ranges of products, can 
be used as a mechanism to overcome the restrictions of traditional feature based design. This 
database, termed a Product Range Model, will enable designers to build product designs based 
on the fimctional needs of the product. This means that the designer has the flexibility of 
working within the general needs of the product functionality rather than being constrained to 
consider directly the manufacturing requirements of the product, as is typically the case in 
design by feature approaches. 

A Product Range Model captures each of the functions which a product in a family can fiilfil, 
along with the alternative ways in which each function can be achieved. The designer of a new 
product in the range is fi-ee to select fi-om these alternatives. Product Range Models can be 
used to capture the functionality of products which are individual component products or of 
more complex product types. A simple illustration of a product range model database showing 
PT-Plus functions, linked to forms, which are in turn linked to mouldability features is shown 
in figure 3. This has been shown to be an effective means of linking between design for 
function and design for manufacture for this type of product. 

Issues still to be addressed in constructing Product Range Models are; 

(a) Can functional features within a product range be linked to multiple manufacturing 
processes in design for manufacture? 

(b) Is there a limit to the complexity of fimctional interaction within a product range which 
invalidates the links to manufacturing which can been made? 

(c) To what extent can sets of functional features, linked to existing product ranges, be 
extended to support new product ranges? 
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Figure 3 Linking Functional Design to Design for Manufacture through Product Range 
Models 



5 INFORMATION SHARING IN DESIGN FOR MULTI-PROCESS 
MANUFACTURE 

The majority of design for manufacture research to date has focused on a single manufacturing 
process e g. design for assembly, design for machining, or design for injection moulding. When 
we consider real design problems there are many manufacturing processes involved and each 
must be able to offer its knowledge input to support design decisions. The distinction between 
design for manufacture for single processes and for multiple processes is drawn in figure 4. 
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(a) Design using a single 
manufacturing process 



(b) Design using multiple, interacting, 
manufacturing processes 



Figure 4 Single and multi-process design for manufacture 
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The majority of products require multiple processes in their manufacture and each can 
influence the design of the product. Systems must therefore be able to provide support which 
meets this need. If we again consider the PT-Plus example, its design, as shown in figure 5, is 
influenced by the mould, the injection moulding machine to be used, the packaging machine 
through which the component is fed as well as the mould manufacturing processes of 
machining, EDM, grinding, etc. The influences of each must be known and fed back to the 
designer when significant. 

The value of the manufacturing model concept is that it provides the means by which the 
capability of each of these processes can be captured independently. It is up to the design for 
manufacture support applications to be able to access the information in such a model in order 
to identify any significant information which should be fed back to the design team. 

While the capability of each process can be captured in a manufacturing model, the more 
critical problem is to provide a data input to the manufacturing model, in the appropriate form 
for each manufacturing process. There is therefore a need to provide a view of product data in 
a suitable form for each process. It is proposed that this can be provided fi-om a product model 
if it can capture the different facets of product data needed for each manufacturing process’s 
viewpoint, as illustrated in figure 6. In addition, there is then a further need for a translation 
process which can maintain the different faceted views of the product data as it is manipulated 
by the various design for manufacture applications. 
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Figure 6 Process Faceted Data for the PT-Plus Example 

An overall view of the elements of a data driven design for multi-process manufacture 
environment is shown in figure 7, highlighting the need for a product range model, process 
faceted data, and a faceted data generator , or data translator, in addition to the multiple levels 
of expertise needed to support each manufacturing process. 
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Figure 7 Design for Multi-process Manufacture 



6 DISCUSSION 

This paper has« discussed the need for radically different design support tools to support 
knowledge intensive engineering activities. It has highlighted the importance of providing 
information support to design teams and the role which both product and manufacturing 
models can offer in doing this. The need for further research into such models is needed as is 
the critical need to understand how application environments can utilise the information 
contained in these model to better support designers. This raises issues both in terms of the 
structure of such environments and the information translation techniques which are needed. 

The use of a Product Range Model to provide support in the interactions between design for 
function and design for manufacture has been highlighted as has its potential to provide a more 
effective design support tool in feature based design systems. A potential route to providing 
design for multi-process manufacture support, utilising these concepts, has been indicated and 
research is currently being pursued by the author to investigate these ideas further. 
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Abstract 

This paper reports on the development of the process-planning module for ED APS, an 
integrated system for designing and planning the manufacture of microwave modules. 
Microwave modules are complex devices having both electrical and mechanical properties, 
and EDAPS integrates electrical design, mechanical design, and process planning for both 
the mechanical and electrical domains. 

EDAPS ’s process planning module provides an integrated approach to process plan- 
ning in both the electronic and mechanical domains, specifically in the manufacture of 
microwave transmit-receive (T/R) modules. It enables EDAPS to generate process plans 
concurrently with design — and we are developing ways for EDAPS to use the process 
planning information provide feedback to designers about manufacturability, cost, and 
lead time for manufacturing their designs. 

The planning module is based on a modified version of an A I planning methodology 
called Hierarchical Task Network (HTN) planning. We provide an overview of its opera- 
tion, and compare and contrast it to how HTN planning is normally done. 
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Figure 1 Design and manufacturing cycle for microwave T/R modules. 



1 MOTIVATION 

In [20], we argued that although AI planning techniques can potentially be useful in sev- 
eral manufacturing domains, this potential cannot be realized without developing more 
realistic and more robust approaches to issues important to manufacturing engineers. We 
further argued that by looking realistically at issues important to manufacturing engineers, 
AI researchers might be able to discover principles relevant for AI planning in other do- 
mains, This paper attempts to address both of these objectives, in a manufacturing plan- 
ning domain quite different from the machining domain described in [20]: the design and 
manufacture of complex electro- mechanical devices. More specifically, this paper focuses 
on the use of AI planning techniques for process planning in the design and manufacture 
of microwave transmit-receive (T/R) modules (described further in Section 3). 

Figure 1 illustrates the design and manufacturing cycle for microwave T/R modules. 




Integrating electrical and mechanical design and process planning 



271 




Figure 2 Integration of disciplines for the design and manufacture of complex electrome- 
chanical devices. 



which is highly interdisciplinary in nature. Electronic designers develop the detailed cir- 
cuitry; mechanical designers design the device to resist shock and vibrational loadings, 
and develop the assemblies, the heat removal systems, and the housing of the device; and 
manufacturing engineers apply electronic manufacturing processes (such as lithography, 
soldering, cleaning, and testing), and mechanical manufacturing processes (such as drilling 
and milling) to manufacture the end product. 

For many manufactured products, the decisions made during the design of the product 
will determine most of the cost of manufacturing the product. This has given rise to 
the philosophy of integrated product and process design (IPPD), which attempts to take 
manufacturing considerations into account while the product is being designed. However, 
in the design of a complex product, this requires coordinating a large interdisciplinary 
team. In large organizations, this can be a difficult tcisk [21]. 

The task of communicating design and manufacturing requirements and design changes 
across disciplines could be greatly aided by a carefully designed computer system that in- 
tegrates both electronic and mechanical computer-aided design (CAD) tools, and provides 
access to process planning and design evaluation capabilities, as shown in Figure 2. Such 
a system could be used for designing both the electronic and mechanical aspects of a 
product, analyzing various aspects of the design’s performance, planning how to manu- 
facture the proposed design, and evaluating the process plans to provide feedback to the 
designers about the design’s manufacturability. 

Few existing computer systems can successfully address all of these issues in a single in- 
tegrated environment — and there are several open questions about the best way to design 
such a system. To explore these issues, we have created the Electro-mechanical Design 
And Planning System (EDAPS)^ a toolkit for microwave T/R module manufacture that 
integrates electronic and mechanical computer-aided design, electronic and mechanical 
process planning, and plan-based design evaluation. ED APS ’s process planning module 
generates process plans concurrently with design, and assists the designers in performing 
plan-bcLsed critiquing of microwave T/R module designs. 

EDAPS incorporates electronic design, mechanical design, and process planning mod- 
ules into a single integrated environment. Its process planning module plans both in the 
mechanical domain, including such processes as drilling and milling, and in the electronic 
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domain, including such processes as via plating, artwork deposition, component place- 
ment, and soldering. This allows ED APS to provide feedback about manufacturability 
and lead time to the designers, based on process plans for the manufacture of the device. 



2 RELATED RESEARCH 

Manufacturability analysis for mechanical designs. Jakiela et al. [16] have built a rule- 
based Design-For-Assembly system that gives feedback about assemblability when the 
designer adds new features to the design. Another rule-based manufacturability system 
was developed by Ishii [15]. Our IMACS system [10] generates the best operation plans 
for machined components and gives feedback about manufacturing infeasibilities in the 
design. However, none of these tools are applicable to the electronic domain. 

Manufacturability analysis for electronic designs. Commercially, several CAD tools are 
available for electronic circuitry design (such as Mentor Graphics, OrCAD, EEsof, and 
MAGIC). These electronic CAD packages automatically check design rules, and some even 
perform manufacturing yield analysis of the design. However, since these packages use a 
two-dimensional representation of the design, they neither represent three-dimensional 
mechanical features nor perform any sort of mechanical feasibility and manufacturability 
analysis on devices. Such tasks would require a three-dimensional solid- model representa- 
tion of the design. Harhalakis et al. have developed a rule-based system for critiquing the 
manufacturability of microwave modules [11], but it is not directly linked to an electronic 
or mechanical CAD system. Feldmann et al. [8] describes a system that integrates elec- 
tronic and mechanical CAD tools for three-dimensional molded printed circuit boards, 
where circuits are no longer in planar configurations. However, these tools and systems 
do not evaluate the designs with respect to cost and lead times. 

Computer-Aided Process Planning. Most CAPP systems work only for purely mechani- 
cal products; [26] gives a comprehensive review of such systems. A few efforts (e.g., [25, 18]) 
have focused on CAPP for electronic applications, but these systems do not incorpo- 
rate many manufacturing processes in the mechanical engineering domain. For electro- 
mechanical designs, Candadai et al. [4] use a Group-Technology-based approach to gen- 
erate high level process plans in both domains for the manufacture of these designs, but 
this system does not work concurrently with an electronic CAD tool. 

Design Integration. The DARPA/MADE program focuses on achieving IPPD goals in 
the manufacture of Complex Electro-Mechanical (CEM) devices [31]. CEM devices, such 
as optical cameras and CD-ROMs, are more complex than the devices considered in this 
paper. As part of MADE, the SHARE project [29] examines how information technology 
tools could be applied to promote collaboration between design teams. 

Tradeoff Analysis. The MSDA advisor [23] evaluates system level trade-offs between 
physical size, weight, thermal characteristics, reliability, cost, performance, and so forth 
in the selection of packaging technologies for components used in PCBs and ceramic sub- 
strates. The EXTRA system [2] does tradeoff analysis for selecting alternative components 
and subassemblies for microwave modules. 
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Figure 3 A typical microwave T/R module, consisting of the MIC substrate, and its 
housing. 

3 MICROWAVE T/R MODULES 

3.1 Introduction 

Most commercial electronic products operate in the lOkHz-lGHz radio frequency (RF) 
spectrum. However, in the telecommunications arena, the range of operating frequen- 
cies has been increasing at a tremendous pace. For scientific and commercial long-range 
defense applications — such as radar, satellite communications, and long-distance televi- 
sion and telephone signal transmissions — radio frequencies prove unsuitable, primarily 
due to the high noise-to-signal ratio associated with radio frequencies. Moreover, the 
lower-frequency bands have become overcrowded due to the overuse of these bands for 
commercial communications applications [30]. 

Consequently, in contrast to other commercial electronic products, most modern telecom- 
munications systems operate in the 1-20 GHz microwave range, and transmit/receive 
(T/R) modules of such systems are termed microwave T/R modules (see Figure 3). Mi- 
crowave design is different from RF design in that the transmission lines that carry the 
signals have distributed impedances associated with them. Therefore, the shape and di- 
mensions of transmission lines, which are unimportant in RF designs, are critical to mi- 
crowave designs. These new requirements impose new challenges on the design procedure. 

3.2 Terminology 

In earlier microwave circuit assemblies, different parts of the circuit were built separately 
using coaxial cables or waveguides^ and later assembled by screwing the parts together. 
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Figure 4 Transmission lines in microwave manufacturing. 



Owing to the size and configuration of the coaxial cables and waveguides, the assemblies 
were significantly large, and the assembly procedure was time-consuming and clumsy. 
These earlier assemblies were replaced by Microwave Integrated Circuits (MICs), where 
all functional components of the circuit are fabricated as artwork on the same planar 
board, using the same fabrication technology. In MICs, functional components such as 
transistors, resistors, and capacitors can be classified as either “integrated” or “hybrid”. 
Integrated components are fabricated as a geometric manifestation of the artwork. Hybrid 
components are assembled separately using techniques such as soldering, wire bonding, 
and ultrasonic bonding. 

MIC technology resulted in a reduction of the size of manufactured devices by several 
orders of magnitude. In MICs, the manufacture and assembly stages of manufacturing a 
circuit are integrated, and thus the lead time for manufacturing is reduced. The next level 
of integration has been achieved by Monolithic Microwave Integrated Circuits (MMICs), 
in which all functional units, including the lumped elements, are fabricated as artwork on 
a single planar board. In this work, we consider the manufacture of MICs only. 

We will use these terms throughout the paper (see Figure 3 and Figure 4): 

• The dielectric is the substrate on which the artwork is laid out, and on which the 
hybrid components are assembled. The dielectric serves as a wave-conducting medium. 
Common materials used are PTFE (Teflon), polyolefin, and aluminum-oxide ceramic. 

• The ground plane is a metallic layer on top of which the dielectric layer resides. The 
ground plane is usually made of copper or aluminum. It provides grounding for the 
circuit and mechanical strength for the device, and it acts as a medium to conduct 
away heat generated by the device. The heat flux of components in MICs, especially 
those that transmit power to transmitters, is generally very high, on the order of 10- 
1000 MW/c 77?.^ [24]. Therefore, heat sinking is critical to the performance of the device. 
The ground plane is the mounting surface for the hybrid components. Thus, machined 
features such as milled pockets and drilled holes are developed on the ground plane. 

• The artwork is an etched circuit pattern containing traces, pads to mount hybrid com- 
ponents, components that are directly fabricated on the circuit, fiducials, and reference 
text elements. Usually, the artwork forms the topmost layer of the dielectric. 

• Transmission lines are traces that carry energy to different parts of the circuit. Fig- 
ure 4 illustrates several possible configurations of transmission lines. The Microstrip 
configuration is the simplest to manufacture. 
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• Vias are through-holes in the dielectric that connect the upper layer to bottom of the 
ground plane. Vias also conduct heat from the upper artwork layers to the heat sink. 

• Surface-mount components are hybrid elements that are assembled on the surface of 
the dielectric. The leads of these components do not go into the dielectric (as opposed 
to the leads of through-hole components, which go through the surface). Surface- mount 
technology is quickly replacing through-hole technology because of the reduction in size 
and the ease of automating the manufacturing processes. 

• Mounting features are usually milled pockets that are used as recesses in which surface- 
mount components will sit. These pockets are especially necessary for components that 
dissipate high heat, because these components need to be directly connected to the 
heat sink. Such components include Gunn diodes and Impatt diodes. 

• The housing is a cast, or machined, metallic enclosure which envelopes the entire assem- 
bled device. These enclosures are needed to provide electronic isolation of the devices; 
to provide rigidity and strength; to make external connections easy; and to dissipate 
the heat conducted from the device heat sinks. 



3,3 Electronic Manufacturing Processes 

The production method used for MICs depends on several factors, such as the choice of 
dielectric material and the degree of integration of functional elements in the design. If 
all elements are assembled as hybrids, then lamination, photomask deposition, etching, 
plating, adhesive deposition, application of flux, reflow soldering, trimming, cleaning, test- 
ing, tuning, drilling, milling, and casting form a superset of the operations used [5, 3]. 
If, however, some components are fabricated as integrated elements, thin film and thick 
film deposition techniques must be used in addition [13]. In this work, we assume that 
the modules are fabricated as hybrid-only microstrip MICs, so that the thin/thick film 
processes can be avoided. 



4 SYSTEM ARCHITECTURE 

In the EDAPS system, we want to provide the designers with CAD tools for electronic and 
mechanical design, and with an integrated process planner for manufacturing processes in 
both the mechanical domain and the electronic domain. Thus the EDAPS system consists 
of three modules that can be invoked from a common user interface (see Figure 5): 

• In EDAPS ’s circuit schematic and circuit layout module^ the designers generate elec- 
tronic circuitry. On top of an integrated set of packages supplied by EEsof’s Series 
IV [6] software, which forms the core of this module, we have developed routines to 
provide us with application-specific information. We address this module in more detail 
in [12]. 

• In EDAPS \s substrate design module^ the designers develop mechanical features of the 
MIC. Bentley Systems’ Microstation CAD software application [19] supplies the set 
of tools required to achieve this functionality. The ACIS [1] solid modeler is used 
internally to represent and provide methods to generate and modify features defined in 
Microstation. We are developing routines in C-|— 1- and the Microstation Development 
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Language to integrate Microstation with the rest of the system and to extract and 
supply relevant manufacturing information. More details are available in [12]. 

• EDAPS ’s process planning module, which is the subject of this paper, creates a process 
plan for the design, and reports the lead time for the design to the designers. The 
process planning module is described in more detail in Section 5. 

• The coordination of these modules and the exchange of data among them takes place 
through a user interface written in the Tcl/Tk language [22]. This user interface allows 
the designers to smoothly interact with the heterogeneous modules of the system. 



5 PROCESS PLANNING AND PLAN EVALUATION MODULE 

To perform process planning for microwave T/R module designs, we use techniques from 
hierarchical task-network (HTN) planning [32, 33, 7]. We have also used this approach in 
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Figure 6 Part of the task network for microwave T/R module manufacture. 



some of our other work [27, 28]. In ED APS, process planning proceeds by taking a complex 
task to be performed and considering various methods for accomplishing the task. Each 
method provides a way to decompose the task into a set of smaller tasks. By applying 
other methods to decompose these tasks into even smaller tasks, the planner eventually 
produces a set of primitive operations that it knows how to perform directly. 

As an example, one method for making the artwork for the MIC is to do the fol- 
lowing series of tasks: precleaning for the artwork, then application of photoresist, then 
photolithography for the artwork, then etching. There are several alternative methods 
for applying photoresist: spindling the photoresist, spraying on the photoresist, painting 
on the photoresist, and spreading out the photoresist from a spinner. This relationship 
between tasks and methods results in a task network^ part of which is shown in Figure 6. 

This decomposition of tasks into various subtasks is important for process planning for 
the manufacture of microwave T/R modules for two reasons. First, the decomposition 
in an HTN naturally corresponds to the decomposition of a MIC into the parts and 
processes required to manufacture it. Second, the ability to include the complex tasks 
“make drilling and milling features”, “make artwork”, “assembly and soldering”, and 
“testing and inspection” in sequence provides a uniform framework that can naturally 
accommodate both mechanical and electronic manufacturing processes. 

Sometimes a particular method can always be used to perform a particular task. For 
example, because spreading out the photoresist from a spinner is so accurate, this method 
can always be used to perform the task of applying the photoresist. Sometimes a particular 
method can only sometimes be used to perform a particular task. For example, because 
spraying on the photoresist is only somewhat accurate, this method cannot be used to 
apply the photoresist if a coupler in the artwork has a gap of less than or equal to 10 mils. 

Certain tasks, such as precleaning for the artwork, are primitive^ meaning that they do 
not break down into any other tasks. Once the complex task of making the entire MIC 
has been broken down into a series of primitive tasks, a process plan has been created; 
carrying out the steps of the process plan results in the creation of the MIC. 

The planning module constructs a set of process plans, and evaluates them to see which 
takes the least amount of time. In some cases, it evaluates a set of incomplete process plans 
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Figure 7 Output of EDAPS’s planner: a process plan in a standard format, part one. 



and discards all bu^ the one which takes the least amount of time. For example, because 
the method of application for photoresist does not affect the method of application for 
solder paste, if the quickest method of applying photoresist is spraying it on, then there is 
no need to generate process plans in which some other method of application is used. If no 
process plans can manufacture the device — because some manufacturability constraint, 
such as achievable tolerance, is violated — EDAPS’s planner reports the failure and the 
reason for the failure to the designers. 

This generative process planning approach allows us to provide feedback about manu- 
facturability and lead time to the designers, based on actual process plans for the man- 
ufacture of the device. Because manufacturing engineers are accustomed to a standard 
format for the specification of process plans, EDAPS’s planner outputs the process plan 
in this format. See Figure 7 and Figure 8. 




Integrating electrical and mechanical design and process planning 



279 



Opn A 


BC/WW 


Setup 


Runtime 


LN 


Description 


005 A 


ECl 


0.00 


32.29 


01 


Pre-clean board (scrub and wash) 










02 


Dry board in oven at 85 deg. F 


005 B 


ECl 


30.00 


0.48 


01 


Setup 










02 


Spread photoresist 
from 18000 RPM spinner 


005 C 


ECl 


30.00 


2.00 


01 


Setup 










02 


Photolithography of photoresist 
using phototool in "real.iges" 


005 D 


ECl 


30.00 


20.00 


01 


Setup 










02 


Etching of copper 


005 T 


ECl 


90.00 


54.77 


01 


Total time on ECl 


006 A 


MCI 


30.00 


4.57 


01 


Setup 










02 


Prepare board for soldering 


006 B 


MCI 


30.00 


0.29 


01 


Setup 










02 


Screenprint solder stop on board 


006 C 


MCI 


30.00 


7.50 


01 


Setup 










02 


Deposit solder paste at (3.35,1.23) 
on board using nozzle 










[.. 


.] 










31 


Deposit solder paste at (3.52,4.00) 
on board using nozzle 


006 D 


MCI 


0.00 


5.71 


01 


Dry board in oven at 85 deg. F 
to solidify solder paste 


006 T 


MCI 


90.00 


18.07 


01 


Total time on MCI 


[...] 
Oil A 


TCI 


0.00 


35.00 


01 


Perform post-cap testing on board 


Oil B 


TCI 


0.00 


29.67 


01 


Perform final inspection of board 


Oil T 


TCI 


0.00 


64.67 


01 


Total time on TCI 


999 T 




319.70 


403.37 


01 


Total time to manufacture 



Figure 8 Output of the ED APS ’s planner: a process plan in a standard format, part 
two. 



6 USING THE SYSTEM 

This section describes the interaction between the various modules of the design environ- 
ment, and the mechanism that integrates these modules into a single toolkit. 

Electronic designers, mechanical designers, and manufacturing engineers usually have 
different requirements for output from the toolkit. For an electronic designer, the inte- 
gration mechanism must be able to give feedback on the lead times of process plans. 
It should also inform the designer about mechanical constraints, such as the maximum 
board temperatures and size constraints on the design. For a mechanical designer, the 
integration mechanism should automatically generate the shape description of the design. 
For a manufacturing engineer, process plans are the most important, because they enable 
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Figure 9 Mixer-IF amplifier schematic circuitry. 



the engineer to determine the ease with which the product can be manufactured, and 
associated costs and lead times. 

We provide the mechanism for the exchange of domain-specific product attributes, 
with the ultimate objective of feeding back plan-based cost, quality and lead times to the 
designers. The integration, highlighted with an example, is explained below. It describes 
the steps which will usually be followed in designing a module. Designers can manually 
change the design during any of the design phases. 



Step 1 Schematic Circuit — Circuit Schematic and Circuit Layout Module 

For the purpose of illustration, we use the example of a Mixer-IF amplifier circuitry [17] 
shown in Figure 9. The designers choose the circuit schematic and layout module 
from the user interface. EEsof’s Libra package is invoked. The designers generate an 
initial network of circuitry based on device specifications. The schematic circuit is 
then simulated, using EEsof’s Touchstone package. The final values of all component 
parameters are listed in Figure 9. 

Step 2 Artwork Layout — Circuit Layout and Circuit Schematic Module 

Assuming satisfactory simulation, then from within Libra, the designers invoke ACADEMY 
to generate the layout of the circuitry (see Figure 10). Once artwork generation is com- 
pleted, the system calls an application program that extracts the product information 
relevant for manufacturing from the design databse, and stores it in C-|-+ classes. 
Finally, the system translates the layout into an IGES file [14], and exports it to Mi- 
crostation for substrate designing. 

Step 3 Mechanical design — Substrate Design Module 

Microstation is then invoked from the user interface. The Microstation kernel reads 
layout from the IGES file and product information from the classes, and re- 

generates the artwork as a Microstation design file. Figure 11 illustrates some of the 
package shapes that will be generated by Microstation. 

As can be seen in Figure 11, milled pockets for high-heat dissipating components — 
such as the diodes and the FET in the example — will be automatically generated from 
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Figure 11 Development of mechanical features on the Mixer-IF amplifier substrate. 
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the size information of their respective packages. When the mechanical design phase is 
complete, information about the location, type, and dimensions of all machined features 
and packaged components are written to a file that is read by the process planner. 
Step 4 Process Planner — Process Planning Module 

As we have mentioned, ED APS ’s planner works by decomposing complex tasks into 
simpler tasks. The initial task, which decomposes into all other required tasks, is simply 
called ‘‘Make board”. 

Consider Figure 11. “Make board” decomposes into “Make plated through-holes and 
features”; “Make artwork”; “Assembly”; and “Testing and inspection”. “Make plated 
through-holes and features” decomposes into “Drill plated through-holes”; “Plate plated 
through-holes”; and “Make features”. “Drill plated through-holes” and “Plate plated 
through-holes” decompose into primitive tasks which we do not discuss here. 

“Make features” is the next task, and because there are features left to be made, it 
decomposes into “Make a single feature”, and “Make features”. This “loop” in the task 
network allows us to decompose a task, such as “Make features”, into zero or more 
subtasks, such as “Make a single feature”. 

“Make a single feature” decomposes into “Setup and side- mill (the bottom cutout on 
the left side of the substrate)”. “Setup and side- mill (the bottom cutout on the left side 
of the substrate)” decomposes into “Setup”; “Setup side- milling tool”; and “Side mill”. 
Because the part is not currently set up on the machining center, “Setup” decomposes 
into “Orient the part”; “Clamp the part”; and “Establish a datum point”. All three of 
these tasks are primitive. 

“Setup side-milling tool” is the next task, and because we just started machining, we 
assume that the correct side-milling tool is not installed on the machining center. Thus, 
this task decomposes into “Install side-milling tool (of the appropriate size)”, which 
is a primitive task. Assuming tight tolerances, “Side mill” decomposes into “Rough 
side-mill” and “Finish side-mill”, both of which are primitive tasks. 

“Make features” continues to decompose until a plan has been created for all five milling 
features and all thirteen drilling features in the substrate. 

The next task of interest is “Make artwork”. “Make artwork” decomposes into “Pre- 
clean for artwork”; “Apply photoresist”; “Artwork photolithography”; and “Etching”. 
In our planner, all of these tasks but “Apply photoresist” are primitive. “Apply pho- 
toresist” has several alternative decompositions: “Spread photoresist from a spinner”, 
or “Spindling the photoresist”, or “Spraying the photoresist”. “Apply photoresist” does 
not decompose into “Painting on the photoresist” in this case, because painting on the 
photoresist is not accurate enough for this substrate. 

As mentioned before, because the method of application of photoresist does not affect 
anything else in the plan, ED APS ’s planner locally decides which photoresist applica- 
tion method is cheapest in this instance — “Spread photoresist from a spinner”, let us 
say — and keeps only that subtask in the plan. 

The rest of the plan is generated in a similar manner, and is output as shown in Figure 7 
and Figure 8. The output of EDAPS’s planner includes: 

• A totally ordered sequence of process specifications that can be used to produce the 
finished substrate from the materials given; 

• Process parameters of all the processes that are required to manufacture the device; 

• Estimates of lead times. 
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The output can be fed back to the designers, with lead-time “hot spots” indicated. The 
designers may then change the design elements, in order to reduce the lead time. 
When the designers and manufacturing engineers are satisfied with the design, the 
artwork elements will be extracted out of Microstation, and the equivalent IGES file 
will be generated and sent to ACADEMY. ACADEMY can then export the design file 
in either IGES format or Gerber format for manufacturing. 



7 CONCLUSIONS 

In this paper we have described the process planning module used in the EDAPS sys- 
tem. EDAPS is a design and process planning environment whose goal is to integrate 
mechanical and electronic design tools in a single platform, and to assist the designers in 
evaluating designs based on the manufacturing plans. The distinct advantage of such an 
approach is the ability to evaluate designs from the point of view of the designers and the 
manufacturers. EDAPS thus highlights a concurrent engineering approach that we have 
taken to reduce the lead times, and to improve the quality in electronic manufacturing. 

The process planning module of EDAPS has been completed, although its knowledge 
base is still being tested and fine-tuned. Parts of the rest of EDAPS are still under devel- 
opment. To date, we have completed the routines to extract and store relevant manufac- 
turing information from electronic designs and the routines that build the manufacturing 
features. Work that remains to be done includes building the routines to generate shape 
representations of packaged component features. 

7.1 Lessons Learned So Far 

Integration of Electrical and Mechanical Design. In order to avoid developing a large 
monolithic system from scratch, we decided to use existing commercial systems for electri- 
cal and mechanical design. In addition to providing ways for the electrical and mechanical 
design systems to exchange information with each other, this required extending the elec- 
tronic design system to keep track of some of the information needed for mechanical design 
so that this information will not be lost when users change the electrical design, and sim- 
ilarly extending the mechanical design system to keep track of some of the information 
needed for the electronic design. 

The disadvantage of using existing commercial tools in this way is that it may limit 
the interaction between the electronic design system and the mechanical CAD system, 
and that in any case translating and transferring information from one system to another 
takes time and work. (In our system, because our feedback was based on the process plan 
for manufacturing, we didn’t have to translate and transfer much information between 
the electronic design system and the mechanical CAD system to be able to feed back 
information about cost and lead time. EEsof’s built-in features automatically handled 
manufacturability feedback.) However, the use of existing commercial tools allows com- 
panies to keep legacy systems in place; in addition, designers can change their electronic 
design system without changing their mechanical CAD system, or vice versa. 

Process Planning and Manufacturability Analysis. Hierarchical task-network planning 
appears to be an ideal approach for generative process planning for microwave mod- 
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ules. The decomposition in an HTN naturally corresponds to the decomposition of a 
microwave integrated circuit into the parts and processes required to manufacture it, and 
HTN’s provide a unified framework that accommodates both electronic and mechanical 
manufacturing processes. 

Although researchers have had great difficulty in developing generative process plan- 
ners that produce realistic process plans for complex mechanical parts, generative process 
planning can be more easily applied to microwave T /R modules. In microwave T /R mod- 
ules, the interactions among mechanical features are much fewer and simpler than the 
complex geometric interactions that can occur in complex mechanical parts as described 
in [10, 20]. 

In many AI planning systems, the way of representing information about the world 
is as a collection of logical atoms (elementary expressions in first-order logic). For basic 
research on AI planning, this approach has a number of benefits. However, in applying 
HTN planning to our problem domain, we found it important to represent the data in 
such a way as to facilitate integrating the planner with the other EDAPS modules. For 
example, in order to communicate with the Microstation modeler, the planner needs to 
access complex geometric information that would be difficult to represent or manipulate 
as sets of logical atoms. Thus, we allowed the representation to consist of arbitrary data 
structures as appropriate for the task at hand. This let us represent the data in a way 
that was often much simpler than the corresponding logical atoms would be. 

Task-Network Decomposition and Total Ordering. HTN planning has long been thought 
to have better potential applicability to practical planning problems than other AI plan- 
ning methods [32], and our experience confirms this opinion. We found HTN planning to 
be quite natural in process planning for complex electro- mechanical devices, because the 
planning hierarchy derives naturally from the part-whole hierarchy of the device itself. 

However, even though EDAPS ’s process planning module is an HTN planner, it differs 
from almost all other HTN planners in that it is a total-order planner. Because its task 
networks are totally ordered, so are all the plans that it generates. Furthermore, it expands 
tasks in the order in which they will be achieved: given a sequence of tasks to accomplish, 
it will always expand whichever task needs to be performed first. 

However, we did not make use of another AI planning technique used in most current 
AI planning systems — the use of “partial-order planning”, in which the order in which a 
planner can construct plans for the goals it is trying to achieve is a different order from 
the order in which it intends to execute those plans. For example, if one wants to fly to 
another continent, a partial-order planner might think about what flight to take before 
bothering to develop a plan for getting from home to the airport. This way, the planner can 
constrain its search space by making some “important” or “bottleneck” decision before 
committing to other less-important steps. However, planning for a task that will come 
later in a plan before one has planned everything that will come before them also incurs 
a drawback: when one is planning for the later task, one cannot know what the task’s 
input state will be, because one does not know what sequence of steps will produce this 
input state. This fundamental source of uncertainty can make the planning mechanism 
much more complex than it would be otherwise. 

In developing EDAPS ’s process planner, we felt that even though situations might 
occur where it might be useful to plan for a later task before planning for an earlier task, 
such situations would not occur often enough to make it worth the trouble to develop the 
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complex planning mechanisms and data structures that this would require. Thus EDAPS’s 
process planner may be described as a “total-order HTN planner.” 

Our experience suggests that total-order HTN planning approach is a promising ap- 
proach in a number of application domains. Not only does it appear to work well in process 
planning for microwave T/R modules — but as described in [27, 28], the same approach 
(and some of the same code!) also works quite well in another very different application 
domain: declarer play in the game of contract bridge. 

In both of our application domains, planning the tasks in the order that they are to 
be executed makes it easy for us to use data representations much more flexible than 
those normally used in AI planning. This makes it much easier to interface the planner 
to external information sources, and greatly facilitates the task of creating the planner’s 
knowledge base. Both of these activities are crucial for the development of successful 
planners in realistic application domains. 

Plan Explanation. Our generative process planning approach allowed us to provide 
feedback about manufacturability and lead time to the designers, based on actual process 
plans for the manufacture of the device. Because manufacturing engineers are accustomed 
to a standard format for the specification of process plans, EDAPS’s planner needed to 
output the process plan in this format. Adhering to this format required a lot of work. 

While this plan explanation may seem a small detail — certainly no advanced AI tech- 
niques were required — it is a crucial feature of EDAPS’s planner. Without EDAPS’s plan 
explanation, its plans would be useless. The issue of plan explanation appears to be im- 
portant, and we are unaware of any formal approaches to plan explanation. 

7.2 Future Work 

In real life situations, designers never obtain a truly optimum design. A design that is 
optimal with respect to cost may have poor yields associated with it. In such cases, trade- 
offs have to be done to attain a design solution that is “somewhat optimal” with respect 
to all the decision variables. 

We plan to incorporate a trade-off analysis module that gives the designers a clearer 
picture of all the cost versus quality trade-off issues that are involved in each design. To 
do such trade-off analysis, models to predict yields and costs are needed. To estimate the 
costs, several formulae are available from standard process handbooks. However, yields 
are more difficult to predict. The simplest yield model associates a historically determined 
yield value with each component. In that case, component design features will have quality 
as an additional attribute. The fundamental assumption with this model is that yields are 
determined solely by components, and not by the processes involved in the manufax:ture 
nor by the designs in which the components appear. 

In fact, processes, components, and board design characteristics all determine the yield 
of the microwave T/R modules. Ball and others [2] consider such interactions between 
processes and parts, and solve the trade-off analysis as an integer-programming prob- 
lem. However, they require individual process-component yield values as inputs for their 
models. For new designs, such as the ones we are considering, it is hard to predict such 
process-component yield values without having subjected the product to several runs in 
production lines. In the future, we will do further research to determine the yield model 
most suitable for our application. 
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Abstract 

This paper is a report of the discussions of three working groups at the KIC-2 work- 
shop. The groups were assigned to discuss System Architectures, Representations, 
and Delivered Systems, and were charged with addressing topics from the point of 
view of Research Achievements, Research Issues, and Industry Needs. 
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1 KIC-OFF 

This paper is a report of the points raised and the conclusions reached by three 
working groups that were formed from the attendees at the KIC-2 workshop. The 
groups were assigned to discuss System Architectures, Representations, and Deliv- 
ered Systems. Each group was charged with thinking about their topic from the 
point of view of Research Achievements, Research Issues, and Industry Needs. 

Much of this paper will be based on the deliberations of the Architectures group, 
as this was the group of which the author was a member, and because it was 
observed that most of the points raised there were also discussed by the other 
groups. The issues from all three groups will be summarized in this paper. 

In order to characterize the achievements of the KIC field we will focus on the 
state of research ten years ago, and then contrast that with current research. The dif- 
ference should reveal the Research Achievements, i.e., which problems the field 
thinks are solved. The description of current research will also reveal the Research 
Issues, as this is what people are currently focussing on. Surprisingly, at first any- 
way, it also reveals the Industry Needs. 
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2 THE EARLY GAME 

By 1986, ten years ago at the time of writing, MP had already had two Working 
Conferences about knowledge-based CAD [Latombe 1978] [Gero 1985]. 

That early research was characterized by attempts to tackle small design prob- 
lems in a single domain (e.g., mechanical), from the point of view of a single 
designer. Research was mostly concerned with the detailed, parametric design of 
single components and simple assemblies, usually using routine design problem- 
solving. 

Many systems were rule-based, although there were some attempts, such as my 
own [Brown & Chandrasekaran 1985], that started to break away from general pur- 
pose reasoning to characterize the knowledge and problem-solving needed for 
design and configuration problems. Most systems were autonomous, responding to 
design requirements with no human in the loop. CAD systems were mostly wire 
frame, with some solid modelling capabilities starting to appear. 



3 ACHIEVEMENTS & RESEARCH ISSUES 

In the last 10 years, research has progressed quite far beyond the situation in 1986. 
Research is now concerned with large designs in multiple domains (e.g., mechani- 
cal plus electrical), and the large systems that design them. These systems often 
incorporate “legacy” systems, and treat design as part of the enterprise - using an 
open architecture, integrating with business systems, and involving physical distri- 
bution. 

The reasoning involved in these design systems is often quite mixed, due to the 
incorporation of real or simulated teams where members have different points of 
view (representing different lifecycle issues, for example), as well as the explicit 
incorporation of multiple types of reasoning (e.g., requirements specification and 
checking, abstraction, problem decomposition, functional reasoning, etc.). 

Many systems concentrate on early design, especially given that a large amount 
of the product’s cost can be locked in at the conceptual design stage. In addition, as 
routine design is quite well understood, most research now tackles non-routine 
design. 

CAD systems are now parametric, feature based, include attributes and con- 
straint checking. Some even include small amounts of intelligent reasoning. 
Achievements in the areas of geometric reasoning and representations have been 
quite strong. Research into features is very active, and their definition, their rela- 
tionship to function, their role in reflecting the designer’s intent, and their depen- 
dence on viewpoint (e.g., manufacturing vs. assembly) are topics that produce 
much disagreement and discussion - and this workshop was no exception. 

There is recognition that designs need to be represented in more than one way, 
at different levels of abstraction, from different viewpoints. This might include 
product-process relations. A key research issue is the need for links across these 
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heterogeneous representations, possibly between modelers, to connect related infor- 
mation and data. 

Embedded knowledge-based reasoning has become quite common, and small 
expert systems are quite widely used, and have had a noticeable impact on the 
design community. Some effort is being given to the design of intelligent artifacts, 
that incorporate knowledge-based action, and knowledge about the artifact itself 
(e.g., for reasoning about diagnosis or repair). 

In addition, there has been recognition of the importance of: 

• the need for design rationale (design intent) capture and use; 

• the fact that both design knowledge and design data is changing over time; 

• the increased use of design-related data bases, brought about by larger designs, 
design reuse, and the use of legacy systems (that may have associated data 
bases); 

• the fact that design is often a discussion between people, with appropriate sup- 
port required; 

• the need to recognize inconsistency in designs and design information; 

• the study of and comparison between design methodology across domains. 

This set of changes in research over ten years points to many achievements that 
have allowed the field to progress to these new topics. For example, routine para- 
metric design is considered to be a solved problem, and CAD systems are more 
properly thought of as solid modelers. 

This set of changes also indicates most of the current research topics. The move 
to bigger design problems, less-routine activity, a stress on earlier design stages, 
with large amounts of varied knowledge raises many research issues. The move 
towards distributed design and the integration of design systems into the existing 
business structure raises* many more. 



4 OUR GOAL 

Research into design representation, reasoning and systems can, quite properly, 
have the goal of better understanding all aspects of design. However, design is such 
a practical area, that we need to have “satisfying the needs of industry” as one of 
our goals. 

The basic needs of industry - making products better, cheaper, and faster - 
haven’t changed much in ten years. However, there is now a recognition that the 
design process has an architecture, that can be examined and refined. Industry needs 
tools which match this architecture that can support both the design process and the 
individuals involved in it. The design process needs to be integrated into the enter- 
prise. In addition, the design process is seen as something that can and should be 
‘instrumented’ to assist with the management of quality. 

Industry is becoming increasingly aware that knowledge is a key resource that is 
important to capture, keep and use. There’s a need for design rationale capture to 
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allow explanations to be provided about existing designs, to guide new designs, and 
to allow easier redesign activities. 

Systems with embedded intelligence are no longer strange - although work 
explicitly labelled as Artificial Intelligence may still be treated with suspicion. 

Even though industry’s basic needs haven’t changed much, business organiza- 
tions and practices are changing, with more distribution of design teams and 
designs. Virtual prototyping has reduced the number of actual prototypes being 
made. There is increased use of existing parts, via catalogs, and existing systems 
(i.e., legacy systems), in order to maximize return on investment. Rapid prototyping 
(real, not virtual) needs to be more strongly tied to design systems. Such needs 
require open systems to ensure maximum flexibility. 

Design in industry is increasingly concerned with life cycle issues and impact 
(for example, as in “green engineering”). Design for manufacturability is more 
common now, and new “ilities” are appearing - it has been claimed that “the num- 
ber of ‘ilities are growing”. 

It should be clear that these observations about “industry needs”, include many 
of current research issues that were discussed above. In addition, the systems deliv- 
ered have addressed some of these issues, with better integration via data exchange, 
increased use of features and product models, wide support for detailed design, and 
growing concern for supporting conceptual design. One explanation for this is that 
design researchers have been listening to industry, and vice versa. Clearly, this 
needs to continue. 

In summary, industry needs distributed, integrated, design systems. There is a 
strong correlation between industry needs and current design research. 



5 AFTER LOTS OF KIC-ING, WHAT’S THE SCORE? 

Ten years ago we were concerned with “IntCAD”, with intelligence in the CAD 
system. Now we are focussing on “KIC”, Knowledge Intensive CAD. KIC has 
knowledge of many types in many places, is concerned with product knowledge 
management, and its relation to lifecycle stages. 
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